Re: [uf-discuss] Re: Microformats UI in Firefox 3

2007-09-04 Thread Breton Slivka
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

2007-09-04 Thread Pelle W

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

2007-09-04 Thread Breton Slivka

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

2007-09-04 Thread Alex Faaborg
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


Re: [uf-discuss] Re: Microformats UI in Firefox 3

2007-09-03 Thread Tantek Çelik
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