Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Tue, Mar 10, 2015 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Yup, and thanks for linking the bug. If it happens at the markup level, it should *definitely* affect the naturalWidth/Height properties. I don't think that's in question at all. But nobody's moved on the markup issue, so I haven't removed the CSS property yet. ^_^ ~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508, but I
think specifying whether we honor EXIF orientation on a per-image basis is not
really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible, is to
just respect EXIF orientation by default.
If we can’t do that, then I think content authors will mostly just opt in via a
single “img { image-orientation: from-image }” in their CSS. That’s the
simplest opt in solution that’s feasible. It’s also trivial to encapsulate in a
standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based solution, as
that will force content authors to specify “autorotate” on every single img
element on the page. That’s a waste of effort and bandwidth (though admittedly
compression will make the impact there minimal), and it makes it more likely
that content authors will simply forget to do so on some elements.
Encapsulating this solution is also significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
- Seth
Re: [whatwg] Persistent and temporary storage
On 14 Mar 2015 05:49, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Mar 13, 2015 at 6:58 AM, Janusz Majnert j.majn...@samsung.com wrote: On 13.03.2015 13:50, Anne van Kesteren wrote: A big gap with native is dependable storage for applications. I started sketching the problem space on this wiki page: https://wiki.whatwg.org/wiki/Storage Feedback I got is that having some kind of allotted quota is useful for applications. That way they know how much they can put away. However, this clashes a bit with offering something that is competitive with native. We can't really ask the user to divide up their storage. And yet when the user asks an application to store e.g. a whole bunch of music offline we don't really want the user agent to get in the way if the user already granted persistence. The real question is why having a quota is useful? Native apps are not controlled when it comes to storing data and nobody complains. Users install a relatively small number of apps, and the uninstall flow (which deletes their storage) is also trivial. Users visit a relatively large number of web-pages (and even more distinct origins, due to iframes and ads), and we don't have any good notion of uninstall yet on the web; the existing flows for deleting storage are terrible. First you need a notion of install. On an android KitKat, open browser tabs are listed in the same way as open apps, which is a first step. Should bookmarks and desktop icons be unified in a second step to indicate installation? Then, closing the tab of a non-bookmarked app would indicate ability to remove local storage (implicit uninstall, but still following typical browser caching strategies). Removing the bookmark/desktop icon would indicate then indicate explicit uninstall. Cheers, Silvia. I think proper solution would be not to restrict the available space, but provide GUI for users to: * see how much space an app uses (if it exceeds some preset amount) * inspect the files in platform's file explorer Yeah, some improved UI flows along these lines would be hugely helpful for this kind of thing. ~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler s...@mozilla.com wrote:
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508, but
I think specifying whether we honor EXIF orientation on a per-image basis is
not really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible, is to
just respect EXIF orientation by default.
Yup, agreed, that's the best solution. Let's make it happen. ^_^
If we can’t do that, then I think content authors will mostly just opt in via
a single “img { image-orientation: from-image }” in their CSS. That’s the
simplest opt in solution that’s feasible. It’s also trivial to encapsulate in
a standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based solution,
as that will force content authors to specify “autorotate” on every single
img element on the page. That’s a waste of effort and bandwidth (though
admittedly compression will make the impact there minimal), and it makes it
more likely that content authors will simply forget to do so on some
elements. Encapsulating this solution is also significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
Agree with all of this. It's still unclear, though, whether the
effects of the CSS property should be reflected in the
naturalWidth/Height properties, which is the subject of this thread.
If we can get away with just always autorotating, the question is
moot, which is ideal.
~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
Dragging dropping an image to save locally, a common image UI
interaction. Regardless of `image-orientation` the file saved isn't going
to change, right?
As a developer my intuition would assume that naturalWidth/Height are
constrained to the physical media and not the EXIF meta data. If you want
the naturalWidth/Height to match, export your media by rotating so the
exif.orientation = 1 (no rotation).
Just my 2¢
On Fri, Mar 13, 2015 at 2:28 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler s...@mozilla.com wrote:
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508,
but I think specifying whether we honor EXIF orientation on a per-image
basis is not really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible,
is to just respect EXIF orientation by default.
Yup, agreed, that's the best solution. Let's make it happen. ^_^
If we can’t do that, then I think content authors will mostly just opt
in via a single “img { image-orientation: from-image }” in their CSS.
That’s the simplest opt in solution that’s feasible. It’s also trivial to
encapsulate in a standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based
solution, as that will force content authors to specify “autorotate” on
every single img element on the page. That’s a waste of effort and
bandwidth (though admittedly compression will make the impact there
minimal), and it makes it more likely that content authors will simply
forget to do so on some elements. Encapsulating this solution is also
significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
Agree with all of this. It's still unclear, though, whether the
effects of the CSS property should be reflected in the
naturalWidth/Height properties, which is the subject of this thread.
If we can get away with just always autorotating, the question is
moot, which is ideal.
~TJ
Re: [whatwg] Persistent and temporary storage
Janusz Majnert j.majn...@samsung.com writes: On 13.03.2015 15:01, Anne van Kesteren wrote: On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception if the device runs out of space for whatever reason. There exists also an issue of perverse incentives. If the browser tells an application how much storage it can use, an application developer is likely to try to use the maximum allowed space. This could also lead to web apps refusing to run if an user agent does not report enough space. One solution I know that tries to deal with that is Linux's OOM killer: If you go over the quota, your program is likely to be eaten by a grue. Native apps are not controlled when it comes to storing data and nobody complains. Is there any documentation on how they handle the above scenario? Just write to disk until you hit failure? I think so. This is certainly the case with desktop apps. I also didn't find any mention of quota in Android download manager docs (http://developer.android.com/reference/android/app/DownloadManager.html) or in Tizen's Download API (https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.apireference/group__CAPI__WEB__DOWNLOAD__MODULE.html) Regards, -- Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
For video the rotation is applied to videoWidth and videoHeight, at least in Chromium/Blink. A video with rotation metadata is thus indistinguishable from one where the frame themselves are rotated. If there's any hope that doing the same for img could be Web compatible, and Safari's behavior makes that seem likely, that seems like a pretty good outcome. Philip On Fri, Mar 13, 2015 at 6:14 AM, Seth Fowler s...@mozilla.com wrote: The more I think about this, the more I agree with David. It really does make more sense to act like the rotation is part of the image format, because after all it *is*, at least when from-image is used. This approach also gives us a smoother path to eventually respecting EXIF orientation by default. If we did that, we’d want naturalWidth and naturalHeight to take EXIF orientation into account, so planning for that with the behavior of image-orientation makes sense. And FWIW, Safari (which respects EXIF orientation in image documents and by default on mobile) does appear to take EXIF orientation into account for naturalWidth and naturalHeight, so this approach is web compatible. Consider this a second vote for “naturalWidth and naturalHeight should respect image-orientation”. - Seth On Mar 10, 2015, at 10:09 AM, L. David Baron dba...@dbaron.org wrote: On Monday 2015-03-09 16:52 -0700, Tab Atkins Jr. wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. I really think that the mechanism for opting in to honoring EXIF should make the browser act as though the rotation were in the image format. It's a compatibility hack (because implementations were initially shipping without EXIF support, and there may be a dependency on that), but once the developer has opted in, everything should really act like the rotation is part of the image format. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
[whatwg] Persistent and temporary storage
A big gap with native is dependable storage for applications. I started sketching the problem space on this wiki page: https://wiki.whatwg.org/wiki/Storage Feedback I got is that having some kind of allotted quota is useful for applications. That way they know how much they can put away. However, this clashes a bit with offering something that is competitive with native. We can't really ask the user to divide up their storage. And yet when the user asks an application to store e.g. a whole bunch of music offline we don't really want the user agent to get in the way if the user already granted persistence. -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Native apps are not controlled when it comes to storing data and nobody complains. Is there any documentation on how they handle the above scenario? Just write to disk until you hit failure? I think proper solution would be not to restrict the available space, but provide GUI for users to: * see how much space an app uses (if it exceeds some preset amount) * inspect the files in platform's file explorer Agreed that we need much more solid UI for users to control sites. I would expect the granularity to be more along the lines of delete all initially, though. -- https://annevankesteren.nl/
Re: [whatwg] Persistent and temporary storage
On 13.03.2015 13:50, Anne van Kesteren wrote: A big gap with native is dependable storage for applications. I started sketching the problem space on this wiki page: https://wiki.whatwg.org/wiki/Storage Feedback I got is that having some kind of allotted quota is useful for applications. That way they know how much they can put away. However, this clashes a bit with offering something that is competitive with native. We can't really ask the user to divide up their storage. And yet when the user asks an application to store e.g. a whole bunch of music offline we don't really want the user agent to get in the way if the user already granted persistence. The real question is why having a quota is useful? Native apps are not controlled when it comes to storing data and nobody complains. I think proper solution would be not to restrict the available space, but provide GUI for users to: * see how much space an app uses (if it exceeds some preset amount) * inspect the files in platform's file explorer Regards, -- Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics
Re: [whatwg] Persistent and temporary storage
On 13.03.2015 15:01, Anne van Kesteren wrote: On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception if the device runs out of space for whatever reason. Native apps are not controlled when it comes to storing data and nobody complains. Is there any documentation on how they handle the above scenario? Just write to disk until you hit failure? I think so. This is certainly the case with desktop apps. I also didn't find any mention of quota in Android download manager docs (http://developer.android.com/reference/android/app/DownloadManager.html) or in Tizen's Download API (https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.apireference/group__CAPI__WEB__DOWNLOAD__MODULE.html) Regards, -- Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics
Re: [whatwg] Persistent and temporary storage
Very timely! A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model a bit granted by the user to an origin, which then requires explicit user action before the data might be cleared under storage pressure, so it sounds like our thinking is broadly aligned, although we're still exploring various possibilities and their implications for permission prompts, cleanup UI, behavior under pressure, etc. Similarly, we've been trying to keep this orthogonal from quota (either the UA's logic for assigning a quota to an origin quota, or possible standardized quota APIs), although the UA may use similar signals for granting permissions/assigning quota. (FYI, we've been using durable and non-durable to distance the discussion from the now-loaded temporary vs. persistent terms which surfaced in earlier API proposals, some of which are implemented in Chrome) On Fri, Mar 13, 2015 at 7:25 AM, Janusz Majnert j.majn...@samsung.com wrote: On 13.03.2015 15:01, Anne van Kesteren wrote: On Fri, Mar 13, 2015 at 2:58 PM, Janusz Majnert j.majn...@samsung.com wrote: The real question is why having a quota is useful? The reason developers want it is to know how much they can download and store without getting an exception. Which still doesn't guarantee they won't get an exception if the device runs out of space for whatever reason. Native apps are not controlled when it comes to storing data and nobody complains. Is there any documentation on how they handle the above scenario? Just write to disk until you hit failure? I think so. This is certainly the case with desktop apps. I also didn't find any mention of quota in Android download manager docs ( http://developer.android.com/reference/android/app/DownloadManager.html) or in Tizen's Download API (https://developer.tizen.org/ dev-guide/2.3.0/org.tizen.mobile.native.apireference/ group__CAPI__WEB__DOWNLOAD__MODULE.html) Regards, -- Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics
