[uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern

[André Luís]

Hi Ben,

Thanks for bringing this up. We need to tackle this, once and for all.
So guys, pitch in and let's try to keep discussion open and towards a
solution.

On Thu, Nov 6, 2008 at 9:53 AM, Ben Ward <lists at ben-ward.co.uk> wrote:

> 2. Violating the principal of visible data
>
> Resolution: Microformats maintain a principal of marking up visible data.
> However, we have exceptional circumstances where the data required for
> parsing is not the data that publishers wish to display. Whilst parsers are
> a lower priority than publishers, the cost and complexity of parsing
> unstructured dates, or translated terms, is accepted as too high. Therefore
> it is necessary to violate DRY to include explicit representations for
> machines.

+1
Empty spans is quite different than empty links (anorexic links,
banned by posh principles)...

>
> Currently authors may use CSS to hide the machine-form of dates.
> Microformats exists only in the HTML layer, and must not depend on CSS to
> meet publisher requirements.
>
> The specification may also restrict this part of the pattern to certain
> properties where a machine-data form is required, as a means to discourage
> abuse.
>
> 3. Broken parsers drop empty elements
>

About this, I can only think of one little issue, something that we
are bound to run into down the road. The WYSIWYG editors for easier
authoring of microformatted content. There still aren't many out
there, but I think most editors at the moment wouldn't show these
empty spans, thus not allowing the user to change its value.

One could argue that when someone actually extends an editor to
support creating of microformats, it would be aware of these empty
spans and render them in a visible fashion, but we need to take into
account the general distributions out there of those editors.

I've added this issue to the wiki and I hope I can test some of them
soon. Anyone has some insight about this?


> So, there aren't many issues against this part of the pattern, and the rules
> for it are coming together. There's likely some feeling about matters of
> taste as to how to achieve this function. This is my favoured version, but a
> lot of the issues resolved here would apply equally to other patterns too,
> so I'd appreciate further input to see if this pattern can be thoroughly
> specified.

I can see this option being adopted by people who are concerned about
accessibility, while others might just go ahead and use the
regular-problem-maker-of-a-pattern the datetime design pattern,
preferring simplicity over accessibility. Right?


--
André Luís