408667 - support native Image capture controls

Status: VERIFIED WONTFIX

(Camino Graveyard :: Accessibility, enhancement)

Description

[jonathan chetwynd]

<input type=file> control which was specific to image capture.
 <input type="file" capture="still"> 

range of possibilities including:
uploading images
presence in game: photo of me in webpage or game, locally only.
input device: using motion detection

http://tinyurl.com/3x95vt
how to implement: developer.apple.com

parity webkit bug 16474

Comment 1

[Stuart Morgan]

We don't invent new HTML controls in Camino. If you want an image capture control, you'd need to get it added to Gecko as a core feature, and I doubt very much that they would be interested in doing so without it being part of any planned HTML development by groups like the WHATWG. The way to extend HTML is through the appropriate standards bodies, not just by filing bugs against individual browsers.

Comment 2

[jonathan chetwynd]

# Stuart, where was HTML mentioned?

http://www.w3.org/TR/file-upload/
being just one possibility.

this is filed as an accessibility enhancement.
the fact is that a significant proportion of the population prefer this form of input for many activities.

please don't close again, without a better rationale.

Comment 3

[Stuart Morgan]

(In reply to comment #2)
> # Stuart, where was HTML mentioned?

In your original report: "<input type="file" capture="still">" is HTML.

> http://www.w3.org/TR/file-upload/

Nothing in that document is at all relevant to your request

> this is filed as an accessibility enhancement.
> the fact is that a significant proportion of the population prefer this form of
> input for many activities.

Feel free to use that as an argument for doing this when you discuss your request with an HTML standards body.

> please don't close again, without a better rationale.

Complying with established web standards is the only rationale I need. Please don't attempt to lecture module owners about the criteria used to evaluate bugs in that component.

Comment 4

[jonathan chetwynd]

#3

Stuart, we seem to have started off on the wrong track...
are you perhaps aware that opera, safari-webkit and mozilla support keyboard navigation in SVG1.1, even though it's not part of any standard?

As Accessibility component maintainer, I'm astonished at your blunt rudeness.
Do you have any knowledge of learning disability?

I wasn't aware that "<input type="file" capture="still">" is HTML.
please could you point me to where it is in the spec?

the web API id highly relevant, and I can only imagine you've misunderstood the nature of my bug report.

Comment 5

[jonathan chetwynd]

http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0056.html

a request to Doug & Chaals who have some understanding of the issue.

Comment 6

[Stuart Morgan]

(In reply to comment #4)
> are you perhaps aware that opera, safari-webkit and mozilla support keyboard
> navigation in SVG1.1, even though it's not part of any standard?

There is a fundamental difference between adding alternate access to existing controls, which is what that is, and actually creating new kinds of controls as non-standard extensions to a standardized language, which is what you are requesting.

> I'm astonished at your blunt rudeness.

I'm sorry that you feel that it was rude of me to attempt to explain how to properly go about getting the functionality you want into Gecko browsers. I thought that would be more helpful than wontfixing without any explanation.

> I wasn't aware that "<input type="file" capture="still">" is HTML.

I'm sorry I wasn't clear. The "input" element is part of the HTML spec. Adding a new "capture" attribute to an HTML element, which is not currently part of any spec, would be a non-standard extension to HTML, which is not something we will do.

I do understand your bug report, and I've done my best to explain why it is WONTFIX. If you still don't understand how your request interacts with the HTML spec, further explanation is really beyond the scope of bugzilla, and you'll need to find someone to discuss the HTML standards process with you in a more appropriate forum.

Comment 7

[jonathan chetwynd]

#6

Stuart, you are being obtuse, the html aspect is but one possibility....
the capture="still" being suggested as a partial implementation by various members webkit developers.

however, for instance #1 item 3 the use of gesture as input does not require any change to any spec, as it might merely represent a means to change the location of the cursor.
as for isntance a head mounted pointer for camparison.

nonetheless there would need to be a method, and as many macs come with cameras, it would be helpful to those people and they represent a significant minority who would prefer and indeed benefit from such an interface.

as the saying goes, you can lead an ass to water...

Comment 8

[jonathan chetwynd]

Stuart,

I do appreciate that you are the accessibility maintainer, no doubt you understand I prefer comments, and closing bugs myself:

No messing with other people's bugs. Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, do not change the fields of bugs you do not own - add a comment instead, suggesting the change.

I don't believe you've understood much of this bug.
"support native Image capture controls" was not the original title, but one believed to be a reasonable stepping stone to my original request, following a discussion on irc #webkit, and expressions of interest.

I've found the mozilla #irc not very social or chatty in comparison.
perhaps we can get a bug opened when you've had a chance to think about the potential benefits...

you never did comment on whether you had any experience of people with learning disabilities and their needs. perhaps you're aware of the formal objection to WCAG2, and with a little effort, you might understand that, given the lack of input to the standards process their needs are not being met.

Suggesting I input to the standards process is a little ironic.

cheers

Comment 9

[jonathan chetwynd]

Attachment: link to local file

Comment 10

[Stuart Morgan]

For the other Camino devs: discussion of the policy issues in the above comments has been taken up in email, so please don't try to address any of it here.

Comment 11

[jonathan chetwynd]

I have today filed two radar enhancement bugs with apple, which if fixed should go some way to resolving the issues raised in this bug.

I hope that with your guidance these are better framed than the current bug.

#5653025 iSight internal: URI & unique local URI
it would be helpful if there was a simple way to link to the internal iSight camera.
web pages and dashboard widgets could then involve the user.
this would require a simple unique uri that was common to all macs such as:
file:///iSight.jpg or similar 

and also a variation for serving on the web similar to:
http://peepo.getmyip.com/~JonathanChetwynd/zanadu.svg
but more likely
http://peepo.getmyip.com/~JonathanChetwynd/iSight.jpg


#5653030 iSight internal: motion detection
keyword: Accessibility
gesture is a vital skill.
the internal camera has the potential to be a useful input device.
motion detection offers the opportunity to control and move the cursor by gesture.