Hi,

great module! I really appreciate the clean markup generated!

Would you consider adding an option to predefine the number of columns to be filled so they can be auto-filled (by your module)? Additionally one could add a break where the column should end, but that would surely make coding it quite complex.

For example, one could either use something like <!--columns 3--> for defining the column count or use several <!--column--> inserts for defining manual breaks. If latter one is detected the module could switch to former behaviour.

That would really be a great thing. Unless CSS3 is standardized and fully implemented in major browsers, one sadly can not use CSS's definition of fluid columns. But what Firefox already does is awesome!

Comments

joachim’s picture

joachim commented

So do you mean that the module code would decide where to break columns to get 3 evenly-sized columns? Interesting...

x-lette’s picture

x-lette commented

Exactly. This could be done by a kind of word count / column number and adjusting the resulting break to the next or previous sentence or paragraph ending. Should not be that difficult and avoids fault-prone handling of self definded breaks.
Additionally you could ignore auto-columnation if there is something too hard to handle within the text like a table for example.

joachim’s picture

joachim commented

I'm wondering if core's teaser break system could be used here; however, it's not always that good. I'm sure I've seen it break mid-word, which is okay-ish for teaser text with a 'read more' link but will look terrible on columns.
I haven't time to work on this at all right now, but I like the idea and will look at patches.

x-lette’s picture

x-lette commented

That would be great!

Teaser breaking is a quite stupid one, I guess. Probably only counting the letters and cutting at a defined place. But I've seen also (not manually split) teasers that were ending at a paragraph. Maybe this is implemented.

I don't think that I will have time to look at the code, understand it (and the rest of the needed Drupal-code) and apply a patch. But if I do, I'll post it right here.

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

I have written a filter that does exactly this. It is a sandbox project, and I have just applied to promote it to a standard project.

http://drupal.org/sandbox/benji/1181988

Perhaps the best reason not to make my filter a full project is if the maintainer of the Columns filter is interested in combining the two. I suggested this several weeks ago: #1192644: Combine modules?. So far, I have not seen any response.

joachim’s picture

joachim commented

I didn't spot that new issue in the queue - sorry!

It doesn't seem to me like the request in this issue and the Multicolumn sandbox are the really the same -- the request is about making columns that automatically split text, whereas the sandbox does lists that number across columns. They do both have the automatic columns feature, that's true. But I'm not sure how this module's working with general text and the sandbox's focussing on lists would combine. What are your thoughts on this?

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

You are right: the Multicolumn filter is much less general, applying only to lists.

I do not think the two filters are similar enough in the way they work for that to be a good reason to combine them. If we do combine them, I think it would make sense for the one module to provide two separate filters.

The main argument for combining modules is that Drupal encourages cooperation: http://drupal.org/node/23789. I think the important thing is to imagine the user's point of view: if someone is searching for a module that automatically generates columns, will it be simpler to have one module show up in the search results that includes two filters, or two modules with one filter each? I know that I have often been frustrated by having to install and test multiple modules when trying to find one that does what I want.

x-lette’s picture

x-lette commented

I think that those two modules would have a lot of code to share and therefore it would make sense to combine them. Instead of two modules offering similar functionality and each reinventing the wheel again they could share same codebase and switch to one or the other (or both) mode according to user input. And the user can decide whether to use only one of the formattings or both without having to hassle with different modules. Combining would make it necessary to re-code some parts of one or both modules but could make maintenance of code a lot easier.
Just my 2ct.

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

I am willing to work on a patch, as long as joachim expresses some interest.