Para probar los miles de complementos que están disponibles aquí, descarga Mozilla Firefox, ¡una forma rápida y gratuita de navegar en la Web!Cerrar
Elige de entre miles de funciones y estilos extra para hacer de Firefox tu propio navegador.Cerrar
|Usuario desde||June 15, 2008|
|Número de complementos desarrollados||1 complemento|
|Calificación media de los complementos del desarrollador||Puntuado con 3 de 5 estrellas|
Este complemento no es compatible con tu versión de Firefox por lo siguiente:
I like this idea, but I have a question and a comment...
Question: Doesn't this require that the calendar host (google, MSE, your work site) be able to both send and receive json data to stay in sync? Otherwise, aren't you the only one in the room with the decoder ring?
Sub-question/idea: can this plugin use a DOM query of sorts to get microformat-compliant hcalendar data and pass the data into the calendar as json? Otherwise, I'm not sure I see this being reliable without everyone playing ball.
Having said that, my comment: I really like that this add-on pushes for newer calendar formating, as it has been shown with both html-compliance and email that the only way to really see change is with a killer-app (like Firefox, etc) but I don't know if JSON is realistic. I say that because I've wanted to see an official XML-based protocol for icalendar for 3 years now (and others have waited at least 10 years), and it is not even close to happening. So while I like JSON, I'm not sure that we'd see it standardized and adopted (and replacing the current icalendar format) any more so then xml.
But If I've missed the point of your add-on, take all of this as free advice as well as a hint that your description could use some expanding.
I think the basic idea of microformats is solid, but still developing, so some of my issues might be with the format rather than with the add-on. Here are the things I noticed and thought needed improving:
* If I export as vcard, the exported file is called "hcard.vcf", which isn't very helpful and can cause file overwrite issues. It ought to take the fn as the title.
* If I don't set an fn class, but only use the given-name and family name classes, the Operator toolbar doesn't light up. fn should be optional, otherwise I'm forced to hide the redundant element(s).
* If I use the "dtstart" and "dtend" classes in anything other than a abbr element, operator doesn't light up for events. Since my page is a schedule, and the schedule is (appropriately) set up in a table, it seems redundant to set the same data in an abbr element when I could just set the dtstart to the table cell.
* If I add a single event to my Google Calendar, I'm redirected to Google Calendar in the same tab, so I lose the page I'm on. At the very least, a new tab should open, but ideally I should be able to choose the location of my gcalendar as an option and not have to do anything at the Google Calendar site (not sure if that's a gcal option).
* If I have a page with a dozen events, I can export the entire calendar as an ics file. It would be nice if I could rename it something other than hcalendar.ics (maybe the suggested title could be a class, like class="hcalendar venue_cal_concerts", or something) or the user could choose the title. It would also be nice if instead of exporting it and then reimporting it to gcal, if I could "add all to Google Calendar".
I know the developer is in need of financial support to get back to this project, so I'm not expecting overnight implementation, but all of these seem fairly natural improvements, assuming they can be done at the add-on level.
Para crear tu propia colección, debes tener una cuenta de Mozilla Add-ons.