Re: [uf-discuss] Re: Microformats UI in Firefox 3
On 9/2/07 4:07 AM, "Jamie Knight" <[EMAIL PROTECTED]> wrote: > hiya, > > I am not so sure that introducing an extra div / element is the way > forward as it is requiring even more of the authors. I tend to agree with Jamie's assessment. > I was under the > impression that part of the idea behind microformats was that the > tools were to do the donkey work of the process. Certainly one way to put it. ;) Yes one of the goals of microformats is to be a bit more publisher-centric in design rather than parser-centric. That doesn't mean that we try to make things completely no work at all for publishers, because clearly we ask a little of them, but it does mean that we ask less of them than most other standards efforts, which ask publishers to learn new languages etc. See the principles for more on this: http://microformats.org/wiki/principles > I know this isn't wonderfully helpful, as i am not suggesting an > alternative (thats for far greater minds than my own) to me the > thought of adding a div to my page is alot more of an ask than a few > semantic class names. I feel that other may feel the same way. It is not only quite a lot to ask publishers to "add another div" to their pages, but actually undesirable from an overall user experience standpoint. *Publishers* of data can't know beforehand all the ways *users* of that data will want to use it. Hence we ask publishers to mark up data semantically, which enables *general* re-use. Rather than asking them to mark up data semantically and with verbs for *specific* re-uses. > just a few thoughts, > > ^licks^ > > Jamie & Lion Thanks Jamie & Lion. In addition, I found this thread *very* difficult to follow, as at some points it seemed like there were implicit proposals for a taxonomy of possible user actions (a really bad idea to try to solve such a huge problem at this point) or perhaps even a microformat itself for possible user actions for which I've seen no research done etc. As far as discussing microformats user interface in browsers in general, please take a look at: http://microformats.org/wiki/user-interface#Browser_Integration Please consider adding concrete user interface ideas/screenshots, proposals, and even challenges/issues there so that we may have a better record of the "latest" version of a proposal along with critical analysis etc. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
sorry for busting in late on this conversation, but let me get this straight, I'm not sure I follow. 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/ object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox Are any of the above points incorrect? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
Breton Slivka wrote: 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox It's more of an addition than a radical change to the microformats which enables the designer to add Firefox-actions right into their own design although such actions will always also be available through Firefox own UI and the suggested addition wouldn't change how any existing microformats would work or should work. It would be totally voluntarily. If it would be part of microformat standard it would work in any tool which implements it. Although I think the suggestion that was made at first wasn't that good, the core problem it tries to solve is relevant: A need for a standardized way for a webdesigner to add interaction between the microformatted data and the parsers actions into their own designs. Could the Microformat community come up witha standard way of interacting with the parsers through JavaScripts or perhaps through new URL:s like mailto: or feed: or in another way? Or is such a standard perhaps out of this community's scope? / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
Okay well, that's a relief. It's amazing though, that we're talking about enabling designers to design, but have only so far mentioned html, javascript and urls. What about putting the design into the design code: css? Would it not be a simple matter of adding selectors for the firefox mf ui elements? example: x-mozilla-add-hcard { visibility:visible; background:orange; border: 1px solid black; } which would select whatever element is the button/link for adding an hcard. -breton On 04/09/2007, at 9:50 PM, Pelle W wrote: Breton Slivka wrote: 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox It's more of an addition than a radical change to the microformats which enables the designer to add Firefox-actions right into their own design although such actions will always also be available through Firefox own UI and the suggested addition wouldn't change how any existing microformats would work or should work. It would be totally voluntarily. If it would be part of microformat standard it would work in any tool which implements it. Although I think the suggestion that was made at first wasn't that good, the core problem it tries to solve is relevant: A need for a standardized way for a webdesigner to add interaction between the microformatted data and the parsers actions into their own designs. Could the Microformat community come up witha standard way of interacting with the parsers through JavaScripts or perhaps through new URL:s like mailto: or feed: or in another way? Or is such a standard perhaps out of this community's scope? / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
1. You guys are proposing a radical change in microformats, and in the way microformats work As Pelle mentioned, we are discussing the possibility of allowing designers to add UI widgets to act on microformats in the content area. I certainly don't think this constitutes a radical change since they would be optional, and we are working closely with the microformats community to make sure we get it right. and have given us just a week to discuss/object If these changes land in a release of Operator that we heavily promote at the Firefox 3 launch, then we will have considerably more time to discuss the various options. If the microformats community really wants to see this feature land in Firefox 3, then we unfortunately will need to move rather quickly. 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 Not at all, these microformats could potentially still show up elsewhere in the browser UI, for instance in a toolbar, or sidebar, or a right click context menu on the microformatted content. 3. said radical change includes inline styles- functionally identical to presentational html tags. We are open to all suggestions. Thanks for the css example, I've added it to our list of possible solutions. The user-action-x class, action:// protocol, and navigator.send javascript method were only proposed to get the conversation going. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. This isn't about a requirement for playing nice with Firefox 3, if Web designers decided they wanted to create buttons to act on their microformatted content, then they would potentially be able to do so. 5. That extra stuff would *only* be necessary for firefox I would be very happy to see the other browsers add similar support. Unfortunately since they aren't developed in as transparent of a manner, we have no idea if they are currently considering this type of functionality or not. One guaranteed way to get them all to seriously consider adding the feature is for us to ship it in Firefox. I hope that clears things up, and my apologies for the confusion. -Alex On Sep 4, 2007, at 4:27 AM, Breton Slivka wrote: sorry for busting in late on this conversation, but let me get this straight, I'm not sure I follow. 1. You guys are proposing a radical change in microformats, and in the way microformats work, and have given us just a week to discuss/ object 2. If radical change is implemented in firefox, all existing microformatted content will fail to work in firefox3 3. said radical change includes inline styles- functionally identical to presentational html tags. 4. In order to play nice with firefox 3, all publishers of microformatted content would need to add extra stuff to their markup. 5. That extra stuff would *only* be necessary for firefox Are any of the above points incorrect? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss