W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: hidden versus discoverable meta-data

From: Tantek Celik <tantek@cs.stanford.edu>
Date: Thu, 14 Jan 2010 20:06:39 +0000
Message-ID: <1488724402-1263499633-cardhu_decombobulator_blackberry.rim.net-1994255615-@bda088.bisx.prod.on.blackberry>
To: "John Foliot" <jfoliot@stanford.edu>
Cc: public-html-a11y@w3.org,public-html@w3.org
John,

I need to clear up some misrepresentations in this thread which are unfortunately likely to be used as bases for making additional false statements.

> @summary joins a host of other data, including
> microformats, RDFa, data-*, and so on in the fact that they don't have
> a default visual display attached. 

This is both a flawed grouping/association and a false "in the fact" assertion as a whole:

@summary is for *human* readable text and has no default visual display, nor do any web authors present it in practice (outside of maybe test/demo pages - not any real world pages/content).

data-* attributes are for *machine* data (possibly human readable but not necessarily so).

microformats mark-up existing *visible* data, and strongly discourage any use of invisible/hidden/dark data (even though such use is technically possible).

So no, it is false to say "they don't have a default visual display attached" - rather, microformats attach to data which already has a visual display.

Similarly, RDFa and microdata (in my understanding) encourage attaching to already *visible* data, a lesson learned from microformats.

In fact the very existence of RDFa is largely a reaction to the widespread success/deployment/adoption of microformats on existing visible data in the few years of their existence, in stark contrast to a decade plus of lackluster adoption of RDF itself (low enough adoption/dataquality returns on the million$/books/PR invested to be called a failure on the Web IMHO) whether in SGML comments in HTML, or in side-files.

Even TimBL is now advocating RDFa now, not RDF (e.g. see his TED talk on Linked Data). Debating it further is perhaps just an academic matter at this point.

Invisible/hidden/dark data rots - known fact in meta keywords, as acknowledged publicly by both Google and Yahoo ignoring them for search.

At Technorati, we saw up to 30% of "feeds" (RSS, RDF, whatever) rot/break/get-ignored as compared to the much more broadly *visible* HTML blogs they supposedly represented.

When people updated their blogs, blog software, themes, plugins etc., things often broke. So they worked at it until their blog looked good (HTML in the browser), and then either forgot, didn't care for, didn't have time for, or were unaware of the broken feeds - hence "invisible/hidden". 

With enough time, and enough "updates", more and more invisible side files break. 

Doesn't matter that they are likely coming from the same database as the HTML - different code path to generate feeds means a different (and ignorable) point of failure. And thus the same phenomena is likely to cause increasing failure over time to *any* other type of generated side-file as well.

We also know from the meta keywords and RSS/RDF examples that exposure to "other tools" is  insufficient - thus the problem with @summary, and any other assertions/assumptions that "the tools will save us" or "users/authors will just use tools" or "it's a UI tool problem".

One can claim that, well, 30% failure is not that bad, or that meta keywords were just an exception,

Or one can learn from those lessons, and:

1. Stop creating any new invisible/hidden/dark data formats/features/patterns which we know would be doomed to eventually contain rotten/dead content.

2. Obsolete or better yet drop altogether existing invisible/hidden/dark data formats/features/patterns and recommend use of visible data formats/features/patterns instead.


Tantek


P.S.
Note that accesskey is not "hidden" just like href on <a> is not hidden. Links are clickable, thus readily revealing/using the href functionally/behaviorally if not literally visibly. While accesskeys don't have a blue underline default styling, they too are readily activatable by the user (in nearly all desktop browsers on a device with a keyboard) and thus usable and effectively visible.


-----Original Message-----
From: "John Foliot" <jfoliot@stanford.edu>
Date: Thu, 14 Jan 2010 10:52:38 
To: 'Shelley Powers'<shelley.just@gmail.com>; 'Tab Atkins Jr.'<jackalmage@gmail.com>
Cc: 'Gregory J. Rosmaita'<oedipus@hicom.net>; <public-html-a11y@w3.org>; <public-html@w3.org>
Subject: RE: hidden versus discoverable meta-data

Shelley Powers wrote:
> 
> 
> I'm not going to get into the semantics of what this type of data is
> called, but @summary joins a host of other data, including
> microformats, RDFa, data-*, and so on in the fact that they don't have
> a default visual display attached. Factually, though, they aren't
> "hidden", in that other tools can see the data, as we can ourselves,
> just using view source.

....or in properly constructed editing environments.  It's a UI tool
problem, not a user problem or implementation problem.  

In fact, should we want to take this further, it could be argued that
'accesskeys' are hidden meta-data too, thus should be considered a
hindrance or barrier and removed from the spec. (and to be clear, I am not
currently advocating that - in fact I've been turned around on
accesskeys). Tab, don't let your eyes and vision be your disability, start
thinking outside of the box a little.

> 
> Regardless, I'm not sure that it matters, except for the fact that
> there's been an unwarranted assumption expressed too frequently in
> these emails that problems will occur if an element or attribute
> doesn't have a default  browser display.
> 
> There's never been any proof to support such an assumption--only a
> hypothesis presented, without any real and tangible way to prove, or
> disprove, the hypothesis.
> 
> I don't think there's any wrong with stating an opinion. But I think
> it's important that we state opinions as such, rather than as some
> form of nebulous unproven "fact".
> 
> If we acknowledge our opinions as such, perhaps our communications
> with each other can progress in a positive manner. And we won't
> necessarily care what adjectives we attach to  @summary, microformats,
> RDFa, et al.
> 
> I don't want to hinder this discussion, but I think we need to be
> careful about expressing opinion as proven fact.

Thank you Shelley for a more metered response than the one that was
brewing in my head.

What she said!

JF


Received on Thursday, 14 January 2010 20:07:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC