Combining efforts of HTML5 junkies

http://drupal.org/project/plupload also does drag and drop upload. It's unfortunate all of the duplication wasn't caught earlier as http://groups.drupal.org/node/72058 makes it sound like you've been working on this for weeks. From here, the duplication of functionality should be minimized as soon as possible to avoid wasting more time and confusing end users. For example, can your form API element work be contributed to #816090: Support HTML5 elements so we don't have two modules that do this?

Uh oh. Yes, we definitely want to combine efforts! And end up with one awesome HTML5 form elements/extend module that is The Module to use, not several different modules that cause confusion and extra effort.

How's the HTML5 form element part of your project going Maulik? Is it done? Barely started? In progress? Do you need help?

I feel like if Maulik is mostly done with the HTML5 forms stuff, those of us working on Elements module should take a deep look at it and consider ending our effort and use Extended HTML instead. If Maulik has been busy working on other HTML5 things (like video and audio) and has not really worked on the form stuff yet, then let's see if Maulik wants to not develop Extended HTML and instead use Elements.

What do you think Maulik?

It doesn't actually look like the module has any support for the FAPI elements yet? At least not in CVS yet.

Hello,
When I had proposed my project in Google Summer of Code 3 months ago there was no work carried out in these fields, so I was temporarily unaware.
I have completed writing out codes for FAPI new field types for Drupal 7 but there are a few problems in it, and is not functioning as I want. I have seen your work for HTML5 Elements and a major section of features has been duplicated unwillingly. Maybe I must have been a bit more cautious during executing my proposal. My work is very similar to the Elements module just the fact that Drupal 7 has different hook functions compared to Drupal 6 for allowing a module to modify Form API elements. (hook_element_info compared to hook_elements).
In case of video and audio elements, I have written the theming functions for the same but what I intend to do is somewhat different.
Suppose someone uploads a video in any format, it must be automatically converted to ogg format which is only supported format for [video] HTML 5 tag. There are Third party APIs like Firefogg API which do it currently. This is exactly what is next on my mind. Automatic conversion of any uploaded video format to OGG for embedding in [video] tag.

Though My GSoC project period is about to end I would like to discuss what we would do for further commercial uses. And I would commit my current work by tomorrow once reviewed by my mentor.

Changing the title to be a bit more explanitory ... saying "Hi & Welcome" to Maulik ... and subscribing

Hello Maulik,

This is a very good article with some advice about working in the Drupal community. It was written by the woman who is now in charge of Drupal 7, a person who got her start in Drupal as a GSoC student, too:
http://www.webchick.net/embrace-the-chaos

It sounds like you have been working away on Extended HTML, alone, wanting to get it to be totally awesome before sharing it with anyone else. Meanwhile this pile of HTML junkies in New York wanted to do something very similar, and we didn't have any idea you were doing anything, so we started our own thing. Our work is messy and in progress, and we've put our code on Drupal.org even though it's not usable yet. We've been talking to each other and lots of other people as we go, using the issue queues on Drupal.org to organize things.

I do think you started you project before we started ours — so I don't think it's that you weren't careful enough in planning. I think it's that we are doing the "Sloppy Sam" kind of approach, while you might be doing the "Perfectionist Pat". (Do read webchick's article linked above!) Who is your GSoC mentor? I'm sad they didn't teach you to post your work along the way.

Please do put your code up now for everyone to see. And let's all take a long look at both approaches. Ideally, we want only one solution, and to put all of our effort together. Then the Drupal world can think "oh, this module is awesome", instead of wondering "hey, wait, these two modules do the same thing, which one is better?"

I guess we should all work on both for a couple weeks longer, and then decide which one is better, and combine our efforts into that one — depreciating the lesser module. It might sound depressing to depreciate a module that was just "finished", but the Drupal world does depreciate duplicate modules all the time. Getting everyone working on one solution will help make that solution better, and make the upkeep more sustainable in the long haul.

HTML5 Tools and Elements doesn't have anything to do with video, audio, canvas, etc. We are focusing on form elements and markup (along with HTML5 Base). So in that way, Maulik, you are doing things that we are not doing.

Oh and perhaps — hey is Maulik's work all for Drupal 7 and the HTML5 Tools team is all Drupal 6 (so far)? Then maybe it's not so much duplication as complimentary-ish. And we can combine it all into one project.

Hello,

Really nice article and someway down the lane I have been working a lot solitarily, though this is my very first time that I am contributing to open source, so I have a bit less experience. Intially I was thinking of supplying patches to the main core files related to Form API and core Upload Module for my features to get implemented but after a lot of discussion on GSoC project page http://groups.drupal.org/node/62878 , where many developers explicitly mentioned that these changes wont reflect in the core for Drupal 7, I decided to create a contrib-module, along with the RGraph Module that I had developed simultaneously for automatic graph embedding using Canvas API.

My project deals with integrating html features only for Drupal 7 and no support has been extended to Drupal 6. I reviewed the Elements Module and it deals with Drupal 6, so if possible we could discuss and merge the two modules into one singular module providing support to Drupal 6 and Drupal 7 also once the stable version of Drupal 7 is released.

One problem that is currently in the Module is that it is using many external JS APIs like Google Excanvas API for canvas support in IE, and Modernizr JS to detect whether the browser currently supports the HTML 5 elements, which i have just included in the code. This part needs to be a lot more looked at.

And it would be splendid if we could have a discussion on the IRC sometimes. I have logged in the channel #drupal-html5 but found it normally inactive. Maybe the timezone problems. I would not be able to come at DrupalCon Copenhagen, I understand you all would be present there.

Maybe it would be better if we could work on our respective modules for 2 more weeks until DrupalCon comes to an end, as you have mentioned earlier. Then maybe we can discuss on the future prospects of the two modules.

My main aim was to see that all these features get integrated in the core of Drupal 8 but a lot of work needs to be done in this regard :)

Hi, we were getting ready to implement elements on our site when I came across this discussion. Has a decision been made to merge? Deprecate one? I'd rather use the module that will be long term than pick one and have to switch later...

Well, as for myself we are going to be porting Elements to D7 and has always been the plan.

Hello crimsondryad,
I think you must continue with the Elements and HTML5_Tools modules to include the necessary features of the HTML5 Framework as being discussed on http://groups.drupal.org/html5
It was really sad of the duplication of modules, and I have been unable to look a lot into the issues later because of my ongoing graduation.

Hello Dave,
I would be willing to contribute and help in whatever way I could later on, once I am able to get some time off my college, maybe sometime during next year holidays.
How are you going on with the Elements Module? Have you begun work on the porting to D7?
Last time I had seen a few months back, it was D6 compatible.

Thanks,
Maulik

HTML5_tools will also be ported to D7 at some point, but we are trying to get as much learning out of the d6 version as possible before moving on to D7 so I wouldn't expect a D7 version immediately after the D7 release