Re: [uf-discuss] rel-tag on delicious
Christian Heilmann wrote: Does anybody know why delicious isn't microformatted? I can only guess, either yahoo is starving the site, or they are against the concept. It sticks out like a sore thumb in my weblife...on occasion when demonstrating Operator to friends I go to delicious assuming they have some, alwasy forgetting because it seems like a perfect site to host MF's. I can ask, but how is a social bookmarking site a perfect example to host MFs? Surely the idea is that instead of keeping local copies (which you'd do if you export microformats) you keep all of them in a central online repository to maintain them. I would say because practically all data shown on delicious can me marked up with some sort of microformat. rel-bookmark would help to separate bookmarked links from the delicious-interface. rel-tag would give users of Operator or similar a possibility of easily viewing the available tags and look some of them up on other sites supporting tags, Technorati for example. hCards and perhaps XFN would enable the user to extract userdata, perhaps for some kind of an addressbook or perhaps for another social network. The latter is described in http://microformats.org/wiki/social-network-portability / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony skrev:
2. Microformats are in page, and there needs to be some way
to indicate the microformats are available on the page that
doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would fit into the web design paradigm
of markup for data, css for design. My slightly different css approach;
create custom css property:value pairs, such as that of
-moz-border-radius.
If something should add anything it should be added by a javascript
which the Firefox people may very well supply. To have CSS instructing
Firefox to add something into the HTML-data seems wrong, it doesn't
really separate the data and content from the design. If something
should instruct anything to add new HTML-data to a document it has to be
either the HTML itself or JavaScripts. CSS can be used to style what's
added, but should do nothing more than that in my opinion because it's
only purpose is to add a deisgn and if it's removed the page should work
equally well - only not as beutiful as with the CSS added.
Let's just have a javascript like the one here below. If Firefox
supplies a microformats object by default then all webpages can rely on
that in Firefox it can easily be extended to add support for newer
microformats like Prototype and other javascript frameworks today
extends basic DOM-objects and such. If someone would like they could
even code their own implementation of such a solution which can be used
in other browsers than Firefox until those browsers adds support
themselves either directly or indirectly through extensions.
script type=text/javascript
if (typeof microformats.hcard == 'object') {
// Add some actions to the page in any way, like this simple and
bad way
document.write('a href=#
onclick=microfrmats.hcard.add(this.parentNode);Add to addressbook/a');
}
/style
There are probably better arguments for choosing a solution like this
over a CSS and/or HTML based solution, I hope someone more experienced
than me can tell us some of them.
/ Pelle W
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Firefox 3 Javascript Semantic Data UI Control
Manu Sporny wrote: Dimitri Glazkov wrote: I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. The SemanticDataUI object would be accessible, from Javascript, using the “semanticDataUI” global variable attached to the currently loaded document. A publisher could disable the semantic data UI in any browser by running the following line of Javascript: semanticDataUI.disableUI(); Users could control whether or not they allow web pages to disable the Semantic Data UI. Most would probably allow web pages to disable the semantic data UI. Publishers could manually disable the Semantic Data UI and use CSS to mark up their hCards, hCalendars, and hAudios. This would give cross-browser UI control to both the users and the publishers without having to do any CSS magic. Interesting! Perhaps semanticData.ui.disable() instead and have functions like semanticData.getDataById and other DOM-like functions and when you have some data you have fooDataObject.action() or something and fooDataObject.dataType just like nodeType exists in DOM etc. Something like a SDOM (SemanticDataObjectModel) standard? / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Farndon, Tony wrote: And I'm with Tony (and others) on the protocol approach. I should, however, add that I do have one concern about the protocol approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari etc will just get a big old unknown protocol error. This is easily countered by the designer checking for the navigator with js or using !--[if IE] and hiding the protocol actions element, but this of course requires extra work on their part. T. That issue could perhaps be solved by either browser extensions or separate programs with similar roles as feed readers has for RSS. It would perhaps not be too mad of an idea to have Thunderbird or something taking care of the microformats for such browsers since Thunderbird and such programs have greater use of the data contained in the microformats. Like the hCard into Thunderbirds addressbook and the hCalendars into the Lightning extension. Alex Faaborg wrote a clever mail about this earlier and presented a few issues and a few possibilites related to protocols. It was then discussed that perhaps there should be one protocl for each microformat? That would if so enable different programs to easily take care of different microformats. You'll find Faaborg's mail here (is this the usual way to share an older mail on a mailing list or how is more common?): http://microformats.org/discuss/mail/microformats-discuss/2007-August/010536.html / 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
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] Microformats UI in Firefox 3
Alex Faaborg skrev: This is a bit of a hack, but it is also considerably easier than asking the author to write javascript to check navigator.userAgent, know which browsers handle microformatted content (and subsequently update this as it changes), and then display the link accordingly. Also, I'm interested in allowing user generated microformatted content to be added to blogs and wikis where javascript is not commonly allowed. A bit of friendly fedback here, not saying that I would be right at all only sending out some thoughts that may be useful or may be garbage. Instead of having to checking whether the userAgent is right or wrong in my javascript - wouldn't it be possible to check for the presence of any hCard-related function instead? This way it would at least be theoretically possible for any web browser to add such a function, either officially or through a third party plugin, and so trigger the website to view the possible actions. It seems a bit unusual to me to have a class like user-action which the browser should find and change to visible and make a link out of or something. Couldn't another solution be to add some kind of a protocol? Like uf://foobar.com/foo.html#bar-hcard Firefox could process such a link by extracting the hcard with the id bar-hcard and for Internet Explorer a third party program could deal with the link in the same way that Skype deals with call: and Thunderbird deals with mailto: or I could choose to hide the link from IE users. This would be a more usual approach because it already exists for other kind of data like mailto: , javascript: , call: etc. / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats UI in Firefox 3
André Luís skrev: One thing I need someone to clarify: Is that div.user-action inserted by the user-agent, in this case, Firefox 3? Or do the authors have to include that code on their pages? This wasn't very clear to me... I've understood that it's inserted by the web developer to enable him/her to implement the Microformat-actions in their own designs and it's suggested that the class user-action should be used to indicate that something is meant to be a link to such an action. On 8/28/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Alex Faaborg [EMAIL PROTECTED] writes The last class is new: div class=user-action style=visibility:hiddenAdd to Address Book/div The text Add to Address Book is hidden by default, unless the browser (or an extension) recognizes user-action ...or unless the user agent has no CSS functionality available. Is that degrading gracefully? What I don't understand in thate example is that the user-action is applied onto a div which doesn't contain any links or buttons. An action is most often initiated by clicking on either a link or a button. Will the browser add such a control? If so the control over the design won't be completely handed over to the designer which it should be. Another problem might be that the browser will be changing the visibility property because that disables the designer from turning of the action-div's visibility. For example - the designer wants the action-button/link to only be shown when you hover over the hCard it's connected to, therefor the designer hides it by setting the visibility property to hidden and changing it upon hover. If the browser then changes the visibility the design won't look like it was intended to. If a class is to be used it should only connect an action and not add anything or change anything about the site. / Pelle W ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats UI in Firefox 3
This idea is really good, the best possible I think.
If there is a need for interaction on a website then the options are
limited to the browser UI and the script languages available, right?
And this way you're suggesting the user will have the possibility of
adding their own interaction with javascript and the user will have a
fallback on the browser UI.
This way there are the fewest possible restrictions for the designers
letting them choose themselves how they would like to solve this problem.
The functionality you previosuly suggested can for example easily be
added by a third party javascript to make it easier for non javascript
gurus to add actions to their sites, but that should really be the job
of such javascripts like it's javascripts like Lightbox job to show
galleries in a fashionable way. The question about any class names would
also be up to such javascripts.
/ Pelle W
Alex Faaborg wrote:
Perhaps instead of new classes and protocols, we could just do this
completely in javascript. Here is a general example, probably all the
function names would end up being different:
div id=hcard-Alex-Faaborg class=vcard
span class=fnAlex Faaborg/span
div class=orgMozilla/div
div class=adr
div class=street-address1981 Landings Dr. Building S/div
span class=localityMountain View/span
,
span class=regionCA/span
,
span class=postal-code94043/span
script type=text/javascript
if (navigator.microformatAware(hCard)){
document.write(a href='#'
onclick='navigator.sendToAddressBook('hcard-Alex-Faaborg')'Add to
Address Book/a);
document.write(, )
document.write(a href='#'
onclick='navigator.sendToMap('hcard-Alex-Faaborg')'Send to Map/a);
}
/script
/div
It seems you'll still need a way for the browser to inject UI for
actions the content creator didn't foresee.
We can include these actions on context menus, and in the browser UI
(similar to Operator's interface). However, I'm not sure content
creators would be too happy with Firefox modifying their pages by
literally injecting UI.
-Alex
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] stickers
What I know about Microformat-stickers is that Jeremy Keith wrote something about such and had some Flickr-photos of them. Url: http://adactio.com/journal/1323/ / Pelle Dimitri Glazkov skrev: Wait, there are stickers? *frantically searches archives* :DG ___ 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] Ufs on bbc.co.uk/music
Michael Smethurst skrev: But that wasn't the demarcation line I was talking about - I meant when does a person become an organisation? Is it a function of production or fame or what? If Bob Dylan is considered an organisation why not Bill Clinton? Let's see if I can express my thoughts in a good way here. What makes it difficult with artists is that some are just artists and others are bands. Politicians and other celebraties are always individuals. Why do you say that Beatles made Yellow Submarine? Because thats the trademark they choosed to put on their music. Here in Sweden we have a rapper who releases music under the trademark of Timbuktu. Everybody knows him as Timbuktu as if that would have been his name - not as many knows him as his real name Jason Diakité. That a musical masterpiece by Elton John is made by Elton John - that everybody knows because he has choosen to write his own name on his music. If I have a company, which I do, I can name that company after me myself Pelle W Inc. or I can name it something else, at least theoretically, that I come up with like Happy Fantasies Inc. or Richard Smith Inc.. If I choose to have my own name as my company name that doesn't make it less of a company name. Right? Can't the same be said about artists? If a artist choose to have their own names as the trademark of their music - it's their choice but it doesn't make the rademark any less of a trademark. I'm just thinking - not saying that this is right at all. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] definitive hCard on a page
Thom Shannon skrev: What would be the way to markup a hCard as being the definitive hCard on a page. For example the page owner or author. My blog has hCards of friends and commenters, as well as my own. But I'd like a programmatic way to identify mine, mainly to access information about me at my openid. Would it be a category? And is there any convention emerging for the name of such a category? What about using XFN and that way defining you as yourself?| For me that would be:| div class=vcard a class=url fn href=http://pelle.vox.nu/; rel=mePelle Wessman/a /div / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Ufs on bbc.co.uk/music
Andy Mabbett skrev: Unfortunately, the database doesn't tell me whether an artist is a person or a group. I empathise - I had the same trouble with bands vs. artist in the relevant infobox on Wikipedia, Fortunately, it is possible for other parameters used there, to distinguish between them. So in the meantime it's the best I can do with available data... I wonder whether no microformats would be better than broken microformats? What do others think? I think that maybe all artist kan be considered a company because frankly their names are trademarks no matter if their own, a bands or something else. Britney Spears or Paris Hilton could both practically be caled Britney Spears Inc. or Paris Hilton Inc. It's better with broken microformats than no - but perhaps it's better broken the way I suggest than the way it is now? / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Paul Wilkins skrev: From: Alex Faaborg [EMAIL PROTECTED] | Mozilla's user experience team is going to continue brainstorming the best way to expose microformat detection to end users, along with the rest of the mozilla community. I'll post updates to this list from time to time, and it will be interesting to see what interfaces and names other people come up with as well. The RSS feeds are accessed in the browser through the feed button. So it makes sense that the microformat data should be accessed through the data button. I do like data, it's concise and is easy to explain. Q: What kind of data can I get from the data button? A: Contact details, calender entries, geographic locations, . . . Q: Does the data button always get the information? A: No, only when the page author has specially marked out those parts of the page. Data sounds good but since RSS also is data the RSS-feed should perhaps be reached from below the data-button to emphasize the similarities. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Alex Faaborg skrev: They imply opening or saving a completely separate document/file The interface model doesn't necessarily have to actually match the implementation model, but yeah, I'm still not a huge fan of the attachments idea. Pointers for: http://tinyurl.com/278y8g Hyperlayers for: http://tinyurl.com/26mqf3 (or layers for short) Those names sound very catchy - but in my ears perhaps a bit too much like something coming from a classic PR-campaign. At least Hyperlayers - image an ad with the text Increase your productivity with the all new Firefox 3 now with hyperlayers. Very cool - but does it actually tell us something? Can't it be kept simple? Does it have to be a new name - couldn't it rather be a description of an action - like data extraction? (Don't know if thats the right spelling though) That would tell what it does and it would be less PR-like and more honest(?) - it's just plain simply describing what this new thing does and that's what I think is most important. Keep it simple. Both of those names have previously been shot down inside Mozilla, ironically enough because some people felt that the interface-level name should emerge out of the microformats community. In the past Web browsers have lagged far enough behind the evolution of the Web that names have already been established (like with Feeds). Well - that is ironic :) Perhaps the real place for this would be among the comments on a YouTube-movie featuring this in action or in blogosphere? But that does however not stop us from having this discussion... / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Alex Faaborg skrev: couldn't it rather be a description of an action - like data extraction? Yeah, maybe just name the button/menu Send Data. I think the sending is probably more important than the extraction. -Alex Send data sounds perfect to me - much simplier than extraction! / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
On 6/27/07, Tara Hunt [EMAIL PROTECTED] wrote: Although I heart the idea of language for non-experts, I'm wondering how public facing Microformats, as a general term, is. I've thought about this before...I can see the specific microformats, like hCard and hCal and hReview being public facing...and, in reality, these are pretty descriptive. Maybe they just need some sort of iconic marker (like RSS has)...which I think has been attempted before. I agree with Tara here. Microformats is interesting for developers because it tells us in what way the solution works but for my mum it would tell nothing. My mom knows however what an address is and what a calendar is and because of that it's the microformats in itself that should be given common names like web feeds for RSS. I don't know but have XML been given a humane name yet? Because XML is to RSS what Microformats is to hCard. If Microformats should be given a more humane name then that would be something about semantics. Semanticdata perhaps - but it wouldn't make anyone happier I think because the only ones who would be interested would be those who already knows what Microformats is. As far as talking about Microformats under one banner, I don't know if the distinction really needs to be made. i think that may be what POSH was trying to say: use plain old semantic html...but even that is talking to developers and advanced content producers. I agree wth Tara here also. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Alex Faaborg skrev: Therefore, uFs don't need a user-facing name - their applications do. If Operator and Firefox 3 are in a category of uF enabled applications, what should that category of applications be called? Or another way of putting it: Feed Readers :: RSS __ :: microformats I would say that Microformat = XML and therefor you say that this reads microformats as much as you can say this reads XML. What you can say is that this reads RSS or this reads XHTML or this reads some other cool XML-namespace and the same is true for microformats - you can say that this reads hCards, that this reads hCalendars etc. NetNewsWire 3 reads hCards and hCalendars for example. But I kind of understand you because Firefox 3 and Operator are supposed to read with plugins and as such can read anything there's a plugin for, but it shouldn't replicate feed readers but rather something above feed readers which perhaps also includes them. Wouldn't metadata-enabled browser be one possible description? All microformats that someones mum would be interested in would contain some kind of metadata - wouldn't it? Another description could be semantically enabled browsing. Both those description should include RSS and other similar XML-namespaces containing metadata/semantics relevant to the browser. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Frances Berriman skrev: On 28/06/07, Thom Shannon [EMAIL PROTECTED] wrote: Exactly! We need a brand and a website that introduces people to the concept, tells them where to get the plugins or the right browsers and possibly encourages them to put pressure on their web guys to implement them, Want x's on your site? Then use Microformats I think better encouragement would come from putting energy into creating tools, plug-ins, examples and tutorials for those people - rather than trying to re-brand something that's already something else re-branded. I agree - and with the adoption of those tools words will naturally emerge that describes the activity in a good way like photoshopping and googling has emerged even though their creators didn't wan't them to emerge... / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: microformats for normal people, like my mum
David Janes skrev: On 6/28/07, Pelle W [EMAIL PROTECTED] wrote: I would say that Microformat = XML and therefor you say that this reads microformats as much as you can say this reads XML. Well, microformats are one thing and XML is another so Microformat != XML. Or do you mean Terminology-wise/linguistically can be used in the same, in which case I ask does anyone say 'this reads XML' as a _marketing_ term. We already have a perfectly good technical name for microformats, i.e. microformats. Both are methods of describing data in a way computers understand which means that it's what is described by those methods that should be named and not the methods because no one but developers really care about them and that's the main problem with giving Microformats a different name I think - it doesn't do anything in itself and the things described by the different standards is so simple and natural that it's hard to give them any special name. What differs a microformat address from a usual address on a webpage? Well - the latter kan be read by computers but it's still the same address so it's still just a simple address. It adds nothing other than the possibility of the browser understanding and extracting it and it's the same with many XML-standards such as RSS - it adds data which the browser/computer can understand and extract. If firefox needs a catchy phrase - then perhaps use Increased ability to extract data from webpages or something - because it's just as basic as that - no new names because a name is only useful for developers who needs to distinguish between methods - but the user doesn't care about the methods - they care about result! / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
Ryan King skrev: On Jun 28, 2007, at 6:13 AM, Frances Berriman wrote: On 28/06/07, Thom Shannon [EMAIL PROTECTED] wrote: Exactly! We need a brand and a website that introduces people to the concept, tells them where to get the plugins or the right browsers and possibly encourages them to put pressure on their web guys to implement them, Want x's on your site? Then use Microformats I think better encouragement would come from putting energy into creating tools, plug-ins, examples and tutorials for those people - rather than trying to re-brand something that's already something else re-branded. I couldn't agree more. I think this discussion is rather unproductive for this community. Just build the tools, design them well and get people to use them. If you never use the word 'microformat' in your application, that's fine. No harm, no foul, no need to build a new brand. To use a cool name for this - do it web 2.0 - we as a relatively small group of which I'm relatively new can't decide what people will call this and FF3 perhaps shouldn't call it something. Everybody can choose their own name and it will - by the power of web 2.0 which microformat is very much a part of - become a good word in the end. Probably none of us here is the right ones to decide something like this... / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo in Firefox 3 (as: Microformats gets strong showing in Firefox 3 UI)
Alex Faaborg skrev: The problem with geo is that it is horrible to show in a UI Mike: I think we should still try to support geo. Exposing the user to geographic coordinates isn't ideal, but I think that it is considerably better than hiding the action entirely. I've been talking to Mike Beltzner (UX lead at Mozilla) about microformats UI over the last week, and we are now considering a UI similar to the one Pelle proposed (http://pelle.vox.nu/koncept/locationBarMenu_pelle_small.jpg), in addition to the mouse cursor change. One could perhaps have map-thumbnails describing the position of a geo briefly? Enabling the user to se if the position is in the USA or in Asia and perhaps in which state without the need of clicking through to an external map service. Perhaps even a thumbnail could be viewed in connection to the notification of the microformat? We are also thinking about using the cursor change for other types of content handling, like links with specific protocols (mailto:, webcal:, etc.) and files that will either download or launch a particular application. So this UI is not specific to microformats, but content handling in general. It could also be done for different file extensons, at least those connected to plug-ins, like the extension Link Alert, https://addons.mozilla.org/en-US/firefox/addon/3199, does today. There's quite some people who are annoyed when Adobe Reader starts up when they thought they opened a website... The difficulty with this could be when the webpage changes to much - if a link to a mailadress is triggered by JavaScript instead of a mailto: to prevent spambots for example. If the user expects a different cursor then perhaps he/she will be confused. Then again - one could have a special JavaScript icon - although a link can be both a mailto: and a JavaScript which directs the click somewhere else... The came thing applies to microformats - if they are moved, hidden or replaced with JavaScript or CSS - like imagereplacement technologies - then my contactinfo in an image might not trigger an icon although I have a hidden microformat for it... Perhaps the solution should be a new microformat which can be used to connect my image with contactinfo to my elements with a hCard? Perhaps such a microformat could also be used to describe what a link that triggers a javascript event actually does? Perhaps it could be made to trick people into believing that they're clicking something else than they actyally are - but that's the same case as if the cursor triggers on a link with a mailto: and an onclick-event. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: geo in Firefox 3 (as: Microformats gets strong showing in Firefox 3 UI)
Toby A Inkster skrev: Pelle W wrote: It could also be done for different file extensons, at least those connected to plug-ins, This would reassert the false notion that there's such a thing as a file extension on the web. Well - nothing is fool-proof and something that ends with .pdf is most of the time is a pdf-document. One could perhaps use mime-types or such - but then one would need to ask the servers for it. So - as I previously suggested - either a new microformat defining the type or just guessing because guessing might be better than nothing. Could such a microformat be designed like a href=foobar.com/foo/bar/ rev=application/pdf perhaps? With pointing to a hidden hCard like a href=samesite#anchor rev=microformat/hcard with or without an anchor defining the position of the microformat? Just pure brainstorming here - I have no idea myself even if this would be good or not. There would perhaps be some use for it? / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI
Alex Faaborg skrev: If the user is viewing a page with microformats and RSS through a secure connection, they will have a yellow location bar containing a favicon, lock icon, feed icon, and microformat icon. We are worried that this is too much visual clutter. Options include things like merging the feed icon and microformat icon, taking security UI out of the location bar, moving some of these things to secondary UI, etc. I would suggest having something like a notification pop-up, like I have modified one of your pictures into: http://pelle.vox.nu/koncept/locationBarMenu_pelle_small.jpg Yellow to emphasize that it's a notification that appears for like 10 seconds if one has that enabled - yellow is the colour for that in the ajax-world as many may know. The notification-pop-up from the URL-bar icon would show the more hidden preferences of a website - like all the metadatas in the likes of RSS, microformats etc. but it could maybe also if the site is secure. If I click the icon - maybe I should get a pop-up-thing again or maybe a sidebar or a dialog should open showing all of the info found. Perhaps that would be a good solution and just to add - I made this mockup, but I'm not behind making anything Firefoxy - I'm just a swedish webdeveloper who's interested in microformats and the modern web ;) / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI
On 6/5/07, Montgomery, Mike [EMAIL PROTECTED] wrote: I like the idea of an icon that is activated when microformat content is available as mentioned by Paul. It would provide an immediate visual cue that information is available without direct user interaction such as having to hover of content or right-clicking. It would also provide a way to indicate information that may be hidden on the page. I picture it being similar to the RSS feed icon. Maybe it is something that also appears in the address bar. I also agree with Mike, Paul and others here. I read that someone raised the question about keyboard navigation and the only real solution to that problem I think would be to lift microformats out of the actual webpage and into the the browser UI. Mike Kaply wrote: I'm considering experimenting with putting a microformats icon on the URL bar similar to the RSS icon, but that would be Operator only. The Firefox folks specifically don't want to clutter up that bar. That would be the absolutely best solution - I hope that the Operator will show the Firefox crew that Microformats isn't clitter. Mike Kaply wrote: The basic problem with Firefox is that they don't want to clutter the UI with something that might not be used a lot (this is a statement about all microformats in the UI) What they referrer to here is whether the users will actually use the microformats and not if the developers will support it - right? Because if the developers don't support it it won't clutter the UI - only if the users don't use it it becomes clutter. I personally think that microformats support would be more popular than RSS-support. The latter has only been adopted by some people and have a bit of a learning curve - a microformat almost doesn't have a learning curve because it is information in a way we've all already worked with. I personally would say that what would clutter Firefox is when it intrudes into my webpage. What wouldn't clutter Firefox is a friendly notification of the presence of some hidden data. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI
Mike Kaply skrev: On 6/3/07, John Beales [EMAIL PROTECTED] wrote: Things can still change, but after talking a bit with the Firefox 3 folks - Microformats are starting to look more and more like they're going to be supported in a big way in the next major release of the browser. http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ That looks great, it'll greatly improve the marketability of microformats. One thing though - and if you could tell me the correct place to let the Mozilla folks know about this - they should be careful about changing the cursor for a microformat - sometimes an hCard, for example, will be the whole page, or at least a large portion of it, so no matter where the cursor is it'll be in the microformat state. I'm the one to talk to. And yeah, I think the cursor isn't so good for that reason. I'm still waiting for someone to come up with the perfect microformats UI. I think that since users now know that you find RSS through the Firefox UI and not on the webpage itself often then it should be the same with microformats. What if I hide some of my microformats just because I have replaced it with an image on another part of the screen? That doesn't mean that my microformats shouldn't be parsed - they should be and since they can't be showed on the webpage they have to be showed in the adressbar or similar like with the RSS - thats the expected place for metadata. There will be sort of a built in API for microformats as far as I have understood. Therefor I think that if there should be something added to the webpage it should be added by me after I have detected microformat-support with javascript and can add the proper buttons myself. Well - thats my thoughts - hope it gives something. / Pelle ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
