Re: ISSUE-73 (Overlap of "predefined vocabularies" with other specifications), was: Concerns about new section "predefined vocabularies"

On Thu, Jul 16, 2009 at 2:17 AM, Maciej Stachowiak<mjs@apple.com> wrote:
>
> On Jul 16, 2009, at 1:35 AM, James Graham wrote:
>
> Ian Hickson wrote:
>
> Do we want to drop support for dragging contact information from the Web to
> native apps just so that we can change which spec holds what? That seems
> weird. (We could split the sections out and have bidirectional normative
> references instead, but that seems to defeat the point of extracting the
> sections.)
>
> That does seem unfortunate but it could also be solved (in a more flexible
> way) by native apps getting support for the HTML5 microdata format.
> Obviously this is less than ideal since it means that many native apps would
> have to be updated compared with relatively few browsers. However it may be
> good enough as a first step. I think it is only a critical problem if DnD to
> native calendar/address book apps is seen as the killer feature of
> microdata. Otherwise it seems reasonable to leave this out initially (i.e.
> for HTML5) and add support for it if it is needed (and implementors seem
> interested) later.
>
> First, browsers are free to add additional types when dragging from a Web
> page to a native app. So it's not like browsers can't do this without the
> built-in vocabularies. In fact, I'm not even sure the HTML5 spec *should* be
> defining what happening when you drag from a Web page to an app.
> Second, the HTML5 spec itself could have hooks for separately defined
> microdata vocabularies that let them define additional UA requirements for
> drag formats. So I don't think bidirectional normative references would be
> required to normatively require this feature, if so desired.
> Third, drag and drop is not exactly the most convenient or discoverable way
> to extract address data. When I get an email with a vCard included, the way
> I add it to my address book is by clicking on it. Launching the address book
> app first and dragging would be a lot less convenient. I would hope my
> browser could give a similarly nice UI. On mobile platforms, there's often
> not even a notion of dragging, or of dragging between apps. So I think it's
> probably jumping the gun a bit to define the UI for transferring a vCard to
> the system address book. Also, drag and drop as the sole way to perform an
> action tends to be bad for accessibility. This is probably an area where UAs
> will want to experiment.
> For these reasons, I think it's probably not so great to define a specific
> UI path to extracting address info in the HTML5 spec.

Agreed.

While I think the microdata feature is very interesting (more so than
I think Hixie does), I don't see the need for the predefined
vocabularies.

Once there are popular microdata formats (just like there are popular
microformats) that browsers feel that they want to support, i don't
see why they couldn't simply add that data into drag'n'drop
information as it's being dragged into or out from a page. Or display
UI that can be clicked on or otherwise activated to launch external
apps to deal with the microformat.

As a browser developer, I'm very interested in the microdata feature
and hope that we can add support for that relatively soon. In the form
of the DOM interfaces described, as well as internal hooks for
extensions to detect and react to microdata.

I'm much less eager to add support for vCard before it has been proved
that that's a format people are using.

/ Jonas

Received on Thursday, 16 July 2009 10:36:01 UTC