Re: [uf-new] Microformats for hidden data
On Fri, Nov 27, 2009 at 9:19 AM, Fiann O'Hagan fia...@jshub.org wrote: What about tabbed content? For example on http://docs.jquery.com/Core/jQuery the examples and source code appear if you click the tab headings, but otherwise they are not displayed, even though they are in the HTML of the page if you view source. The page is HTML with everything visible, with certain portions of the text hidden from view when JavaScript is enabled and I believe jQuery UI are moving to use ARIA to provide hints for screen-readers which are JavaScript aware. So I'm unclear what the issue is, or why Microformats are needed here. -- Paul (psd) http://blog.whatfettle.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On Fri, Nov 27, 2009 at 9:19 AM, Fiann O'Hagan fia...@jshub.org wrote: I was thinking about this last night, and realised that this is critical. What precisely do you mean by visible in the context of microformats? --- the way I always think about it is, out of sight, out of mind. Files that you may link to, but are not visible in the browser on a daily basis tend to get crufty and the data drifts from reality. I used to have flat vCard files on my server, because i was not staring at them every day through the browser window i forgot to update my address, and the data was incorrect. (How many people actively are keeping their FoaF files current via a text editor? All these files are fine, but the originating source should be very visible to people for editing) The same applies to meta elements or hidden data in HTML. If you are not visibly looking at it every day, there is a potential for the information to be wrong. We´re not talking about if it is visible when you view source, you don't browse sites by viewing source after following a link. Microformats have always tried to promote that the data being encoded is visible, as in rendered in the browser normally so people can see it (with many eyes all bugs are shallow) and if there is a problem, it gets fixed quicker due to this high visibility. It's the final case which is most closely related to what I am proposing here. They have information which is part of the page but it is neither hidden metadata, nor is it rendered in a default view. It is intended to be visible to a different audience than the casual end user browsing the site. --- i would say that it is best to avoid display:none on your content. Yahoo! has chosen to do so, I personally wouldn't recommend it, but their audience is very different than mine. Had they shown GEO coordinates it might confuse their customers. They made a choice to hide it and take the risks of data drift. It is their call to do so. The microformats still work, but they are not promoted to be used in this way. Everything SHOULD be visible by default. I want to do the same thing, which is to add information to the page, in such a way that it is accessible to humans looking at the source of the page, and to people with the right parser in their browser, but is not part of the view generally presented to end users. --- this is where microformats are designed to work in the opposite direction. ALWAYS visible by default. You are asking for hidden by default, which is a recipe for crufty data. Microformats were always designed with people in mind first, this seems to be designing for scrapers first but accessible to people. If what Yahoo Local are doing is not an acceptable use of microformats, then I accept that it's not the right approach for us either. --- I wouldn't advocate the hiding of the data, but they have their reasons and take the risk. But in the world of mashups, scraping, screen readers and all manner of different ways of consuming HTML, it seems like a very artificial restriction. --- well, we can look at it in a different way. Would you trust a smaller set of data that has a higher probability of being accurate, or loads of hidden data that has a higher probability of being inaccurate? Search engines took the first approach. None that i know of still utilize the meta keyword element. It was hidden data, it drifted from reality, and wasn´t reliable (but it was everywhere). Instead they look at rel-tag and visible data (who knows their algorithms might even punish or ignore display:none) and use the more trustworthy data instead. Microformats have been shown to work in the real world already with consuming applications and mash-ups. I don´t think this very artificial restriction has been as big of a problem as you might think. I hope this explains abit more about visible and hidden. -brian -- brian suda http://suda.co.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
Hello Brian, All Brian Suda wrote: ... Search engines took the first approach. None that i know of still utilize the meta keyword element. It was hidden data, it drifted from reality, and wasn´t reliable (but it was everywhere). Instead they look at rel-tag and visible data (who knows their algorithms might even punish or ignore display:none) and use the more trustworthy data instead. As far as search engines go Google *may* punish you for hidden data ( particularly for links and keywords ) because as Brian said hidden data on your website is perceived as untrustworthy. Google webmaster guidelines says this (amongst other things)... If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable. http://www.google.com/support/webmasters/bin/answer.py?answer=66353 So really hidden data is not good for the web in general not just microformats. Microformats are all about what you can see...and not at all about what you cant. Thanks -- Martin McEvoy WebOrganics http://weborganics.co.uk/ Add to address book: http://transformr.co.uk/hcard/http://weborganics.co.uk/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
Brian, thank you for the very detailed response. I do understand this better now. I completely agree about the issue of out of sight, out of mind. It's exactly the problem that applies to web analytics data now. What I want to do is to bring the data a little more out into the visible world. What typically happens on big enterprise sites is that they have an analytics product which requires certain per-page metadata, such as a page name and category. This is different from typical installations of the free tools like Google Analytics, partly because these are larger, more complex sites with deeper analytics needs, and partly because they often have horrible legacy URL structures which makes it impossible to just record visits to URLs. There is a lot of existing deployment of these tags, see for example data at http://www.jgc.org/blog/2009/10/some-real-data-about-javascript-tagging.html Our overriding interest is in making the data available to more than one tag on the page, so that the data doesn't have be declared multiple times in different formats. It's certainly possible to do this purely in JavaScript, where the data is currently declared. But the secondary goal is make the information a bit more accessible for the people who are responsible for the content. Many of them are editors who are reasonably comfortable reading html, but won't touch JavaScript because it is programming. Hence the interest in potentially using microformats. Right now, the editors who are responsible for populating the data, and the analysts who are the audience, commonly have no access at all to check whether it's correct or correct any issues. Would you trust a smaller set of data that has a higher probability of being accurate, or loads of hidden data that has a higher probability of being inaccurate? I agree completely completely with this sentiment. But my question is, given that there is data which is already hidden, crufty and out-of-sync, can we do something to shed a little more light on it? I hope this helps explain where we're coming from. Fiann ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
Brian, that's exactly what I am hoping to do, you have captured it precisely.
hAtom gives a lot but not all of what I am looking for (my baseline is
the fields that are common to all the major web analytics products).
hAtom is focussed on blog posts rather than generic website pages, and
I am not sure it is an exact fit, but the core concept is very
similar.
The reason I am interested in using microformats is that if by using a
standard, I can turn your suggestion of
var page = $('.entity-title');
into hAtom format
var page = $('.hfeed .hentry .entry-title');
and it will work across any site with that markup, which is much
better than defining our own POSH format specific to a single site.
Thanks again for all the detailed feedback and putting up with this long thread.
Fiann
2009/11/27 Brian Suda brian.s...@gmail.com:
On Fri, Nov 27, 2009 at 2:12 PM, Fiann O'Hagan fia...@jshub.org wrote:
What typically happens on big enterprise sites is that they have an
analytics product which requires certain per-page metadata, such as a
page name and category.
--- yup, I know them well. One solution would be to define your own
POSH format and/or re-use something like hAtom.
Then in the JS code for declaring variables for tracking you can
reference the microformats, for instance:
Instead of:
var page = news-index;
var campaign = news
you could replace the declared variables with references to the
visible text such as:
var page = $('.entity-title');
var campaign = $('a[rel=tag]');
In the JS you are referencing visible data. As editors change fields
in the CMS, the tracking codes, campaigns, sections, and other
tracking is done automatically. What you need is the mapping between
the visible parts of the page and your specific tracking variables. It
also depends on how much you want to connect the two and/or allow
editors to be changing these values.
-brian
--
brian suda
http://suda.co.uk
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
Hi Scott, Tantek suggested: 2. use the data-* attributes in HTML5 which were explicitly created to handle the use case of data attributes for scripts/script libraries among other things. You replied: The prohibition of using data- attributes for public data seems to be a problem with this particular use case, as analytics engines are generally independent of the site being tracked and These attributes are not intended for use by software that is independent of the site that uses the attributes. I believe you misunderstand the restriction on data-*= attributes. Here's how James Graham explained the restriction recently on the HTML WG mailing list[1]: [A] third party js-library is not considered independent of the site (since the site must decide to import the js-library into its pages). [...] To take a slightly different example, it is OK to have data-marquee that is used by a script that the author includes in the page to implement marquee effects. But it is not permitted for a user agent to provide its own marquee effects based on the presence of a marquee attribute. -- Edward O'Connor hob...@gmail.com 1. http://lists.w3.org/Archives/Public/public-html/2009Oct/0630.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
