Summary
===
The img element should expose a readonly naturalOrientation
property that returns the EXIF orientation of the image (an integer
1-8), or 1 if the image has no EXIF orientation metadata or it is
corrupted or the image type doesn't expose EXIF data at all.
Background
==
On Fri, Aug 26, 2011 at 11:37 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Summary
===
The img element should expose a readonly naturalOrientation
property that returns the EXIF orientation of the image (an integer
1-8), or 1 if the image has no EXIF orientation metadata or it is
On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Aug 26, 2011 at 11:37 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Summary
===
The img element should expose a readonly naturalOrientation
property that returns the EXIF orientation of the image (an integer
On 11/08/26 10:03, Tab Atkins Jr. wrote:
On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard gl...@zewt.org wrote:
Rather than baking magic EXIF constants into the API, would it make more
sense to translate to degrees?
Possibly. However, 4 of the EXIF orientations (2, 4, 5, and 7) are
unnatural
Le 26 août 2011 à 11:37, Tab Atkins Jr. a écrit :
The img element should expose a readonly naturalOrientation
property that returns the EXIF orientation of the image (an integer
1-8), or 1 if the image has no EXIF orientation metadata or it is
corrupted or the image type doesn't expose EXIF
On Fri, Aug 26, 2011 at 11:13 AM, Karl Dubost ka...@opera.com wrote:
Le 26 août 2011 à 11:37, Tab Atkins Jr. a écrit :
The img element should expose a readonly naturalOrientation
property that returns the EXIF orientation of the image (an integer
1-8), or 1 if the image has no EXIF orientation
Maybe someone should ask the browser vendors how many img formats they
support and what the code footprint memory overhead would be for
adding rotation support for those which are likely to need it at
whatever confidence level you feel is appropriate.
On Fri, Aug 26, 2011 at 9:57 AM, Glenn
On Fri, Aug 26, 2011 at 11:10 AM, Mark Callow callow_m...@hicorp.co.jp wrote:
On 11/08/26 10:03, Tab Atkins Jr. wrote:
On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard gl...@zewt.org wrote:
Rather than baking magic EXIF constants into the API, would it make more
sense to translate to degrees?
On Sat, 9 Apr 2011, Alex Vincent wrote:
I'm working on DOM-based editing tools in my spare time, and have been
for several years. I use DOM mutation events to build transactions -
objects which let me undo DOM mutations and redo them.
[snip discussion of UndoManager and mutation events]
On Fri, Aug 26, 2011 at 2:08 PM, James Salsman jsals...@gmail.com wrote:
Maybe someone should ask the browser vendors how many img formats they
support and what the code footprint memory overhead would be for
adding rotation support for those which are likely to need it at
whatever confidence
Thanks, Ian. I've been loosely following the UndoManager discussion -
reading all the e-mails coming through. I haven't thought about it for a
couple weeks, though. I'll take another look at the current draft soon.
I'll need some time to come back to mutation events.
Alex
On Fri, Aug 26,
Le 26 août 2011 à 16:49, Tab Atkins Jr. a écrit :
If Flickr uses this CSS property, and does so
in different ways in the two places, that's just a Flickr bug.
nope
Flickr offers tools to process images.
Flickr offers hosting of images.
People using the hosting do not necessary use Flickr CSS
12 matches
Mail list logo
