Re: HTML Media Capture draft from Device APIs and Policy Working Group

On Thu, Jul 22, 2010 at 10:52 AM, Andrei Popescu <andreip@google.com> wrote:
>>>> It's telling that the example markup you gave results in almost the
>>>> same thing bring displayed to the user. Actually, my proposal results
>>>> in slightly improved UI since only one text field next to the two
>>>> buttons. Your example results in two separate fields. (Usually file
>>>> controls display a button for selecting a file, and a text field for
>>>> displaying the name of the selected file)
>>>>
>>>
>>> Yes but in my example the application controls the style and position
>>> of each of the buttons. This is what our Web app wanted.
>>
>> Position I understand, but how do you control the style of the buttons
>> in your example?
>>
>> Can you show an example that for example makes the
>> background of the button green? Note that
>>
>> <input type=file style="background: green">
>>
>> does something else in at least current chrome builds.
>>
>
> I am not sure how the application in question does it but there
> certainly is a solution for that. And that's what's important here:
> that it's possible to control the style of these buttons.

Without knowing how you plan on solving the use case for your
proposal, it's hard for me to answer how I would solve it in my
proposal.

Whatever syntax you use to style one of the buttons in your proposal,
would likely allow you to style both buttons in my proposal. I think
there are pseduo elements defined in some CSS spec which might be
useful here. If we can give the pseudo-elements arguments, we could
probably even allow you to use different styling on the two buttons if
people really want to do that. But that doesn't seem terribly
important to me.

>>>> You can even improve on my proposal. Display above two buttons for all
>>>> <input type=file>. That will enable users to use the camera to attach
>>>> a picture in literally millions of pages that exist on the web
>>>> already.
>>>>
>>>
>>> But we do that already (with actually 4 choices), except that one
>>> extra click is required: first click on the single <input> button in
>>> the page, then click again in the resulting native file picker dialog
>>> to select the source.
>>
>> That one extra click is all we're trying to avoid in this thread, no?
>>
>
> In this thread we were discussing the usefulness of the 'capture'
> parameter which would solve all three problems: extra click,
> positioning and styling. I agree that this is only useful to new
> applications and irrelevant to the mass of exiting Web pages. But the
> reality is that we have new applications being developed and that
> require more control over the file picker. I don't see why we
> shouldn't let them do so if that results in better user experience.

My point is that it seems to me like you can get 80% there without
requiring any special markup on the page. And you can get 100% there
by just looking at the mime-types main parameter. I.e. display an
extra camera button for @accept="image/...", an extra microphone
button for @accept="audio/..." and an extra video button for
@accept="video/...".

>>>> That is what we're hoping to do for firefox.
>>>
>>> So you won't support the use case I mentioned since the app won't be
>>> able to place the buttons in a way that suits their UI.
>>
>> The final call isn't mine, but at least not for now now. But we will
>> make it easier for users to use cameras on millions of pages. IMHO
>> that's a bigger win.
>
> But I am not sure I understand what prevents you from doing both. You
> can render your two buttons for the existing millions of pages. If
> some new pages do specify the capture parameter, you can just hide the
> irrelevant button. What is the drawback to that?

That could be an ok solution I agree.

/ Jonas

Received on Thursday, 22 July 2010 18:22:27 UTC