Re: Seeking Comments on Powerbox

On Mar 4, 2010, at 7:18 AM, Tyler Close wrote:

> Hi Maciej,
>
> On Wed, Mar 3, 2010 at 5:45 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> On Mar 3, 2010, at 5:50 AM, Arthur Barstow wrote:
>>
>> FYI, an email from Robin Berjon (one of the DAP WG chairs) seeking  
>> comments
>> re the "Powerbox" spec by Tyler and Mark.
>>
>> The use of <input type="file"> in this spec is out of line with  
>> HTML5 in a
>> number of ways. Here are some examples:
>> 1) The proposed use of alt, title and class attributes is in  
>> conflict with
>> HTML5. This is especially serious in the case of alt since alt is an
>> accessibility feature.
>
> Could you provide some explanation of this conflict? I believe all of
> the named attributes are being used as specified by HTML4. In
> particular, the use of alt is both inline with the specification and
> encourages page authors to improve accessibility. HTML4 says:
>
> "For user agents that cannot display images, forms, or applets, this
> attribute specifies alternate text."
>
> The Powerbox draft says that the alt attribute should describe the
> purpose of the <input> element.
>
> These are much the same reason. Moreover, other than accessibility,
> HTML4 provides little incentive for authors to populate the alt
> attribute, so many don't. The Powerbox creates an additional incentive
> to properly fill out this attribute, since the value is sent to the
> Provider web site as the reason for the request. If Powerbox were
> widely adopted, I believe it would significantly improve accessibility
> via the alt attribute.

Note that I'm talking about HTML5 requirements, not HTML4. I didn't  
check HTML4 because it is effectively obsolete.

alt:
    - When alt does appear, it is required to be a textual  
alternative. HTML5 has an extended explanation for the kind of text  
that goes here. <http://dev.w3.org/html5/spec/Overview.html#alt>. I  
don't think "customer's reason for the request" to a textual  
alternative.
    - HTML5 refines HTML4's muddy conformance rules for alt on <input>  
elements, it is now mandatory on <input type=image> and disallowed on  
all other types of <input>s, see: <http://dev.w3.org/html5/spec/Overview.html#the-input-element 
 >.

title:
    - Title is in general allowed to contain free text that provides  
advisory information, usually shown on hover in typical browser  
presentation. It's generally not restricted to a particular purpose.

class:
    - class is intended for use by the author as a styling or  
scripting hook, or to express semantics. In general authors are free  
to use any space-separated set of tokens. It conflicts with the  
purpose of class to give it UA processing requirements on certain  
elements, rather than freely allowing any syntactically correct value.


>
>> 2) Putting a URL in the value IDL attribute does not match the HTML5
>> implementation requirements for this attribute.
>> 3) It's not obvious how the "files" IDL attribute would be  
>> implemented.
>> I haven't yet had a chance to properly review this proposal at a  
>> conceptual
>> level, but I think if it's going to use <input type="file">, it  
>> should be
>> made consistent with HTM5.
>
> The text under form submission explains how a user-agent can treat a
> file control populated by the Powerbox as compatible with one
> populated by selection from the local filesystem. See:
>
> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html#submit

Points (2) and (3) are about scripting APIs, not behavior of form  
submission.

> My goal in using the <input type="file"> attribute is to provide
> legacy compatibility with current HTML content. This goal should be
> consistent with compatibility with HTML5. I appreciate your assistance
> in creating this compatibility.

My main recommendation would be to use HTML5 instead of HTML4 as the  
baseline reference, at least if it is a goal for the Powerbox  
specification to be implemented in mainstream browsers. Even thought  
HTML4 is the standing Recommendation, it is often vague, inaccurate,  
and out of date; and browser implementors are using HTML5 as the  
relevant reference.

Other comments after reading somewhat more:

- It would probably be a bit easier on readers of this spec to refer  
to implementation requirements as requirements on "the implementation"  
or "the user agent" rather than "the Powerbox".

- It seems to me that the reason for using <input type=file> is so  
that the fallback in browsers that haven't implemented Powerbox is a  
file picker. It's not clear to me that this is always appropriate. For  
the spec's examples of geolocation or device orientation sensors,  
there's not really a file the user could provide that would be  
meaningfully equivalent. Even the spec's more elaborated example of  
live video seems a little off - is choosing an arbitrary video really  
a an appropriate equivalent?

- There's no obvious way to feature-detect Powerbox functionality up  
front, so content could not even use script to provide a different  
fallback (such as indication that some aspect of the site's  
functionality is not supported.)

- On at least one popular device with a camera, a microphone, an  
orientation sensor, and geolocation, namely the iPhone, there is no  
user-visible filesystem, so <input type=file> would be an  
exceptionally bad fallback.

- It's not clear if Powerbox implementations should allow the user to  
choose files in addition to service providers or not.

- The idea of the user being able to choose either local or remote  
providers of a particular kind of service is a good one.

- <link rel=provider> as a way to declare a provider does not seem to  
give the implementation any information on which providers can provide  
which types of resources. It would be a bad experience to list all  
providers for all kinds of resources in the context of, say, choosing  
a video stream, only to result in an error message after the user  
picks an inappropriate provider.

- It seems that to make good use of this functionality, it would be  
necessary to specify the protocols to talk to common kinds of services.

- The proposed protocol for video feeds, which results in uploading  
the feed to a remote server, is probably not the most useful way to  
handle camera input. Usually it is desirable to show the video being  
recorded on the client side. It would be remarkably inefficient to  
upload a video stream to the server and download it back to the client  
for this display.


I gather the proposed 'device' element takes the alternate approach of  
creating a whole new element. I haven't had a chance to review it  
closely but it might be instructive to compare. In general, my sense  
is that it would be a better approach to create new elements and  
attributes where necessary to support this kind of functionality.


Regards,
Maciej

Received on Thursday, 4 March 2010 16:53:50 UTC