Re: [css3-images] [css3-background] Image/media fragments and cropping

Severe compatiblity issues expected !

HTML does not define that (even if it may embed a part of the SVG schema in
HTML5) ! Without an adaptation layer to transform a content type (HTML)
into another (an image or video) and control how the transformation may be
performed, this won't work correctly and interoperability issues will
appear immediately between contradicting specs.

====

Note that if I spoke about javascript URLs this is not stupid : Yes there
are security issues, but the same is true with ONLY basic URLs to plain
image content types (notably because of their format). Javascript is not
less secure than an expected SVG or PNG, they all depend on how each
content type is rendered and the set of permissions and properties exposed
by the respective renderers. We've already seen security attacks performed
using JPEG and GIF images for example, or using data compression schemes.

All these concerns are implementation-dependant, but Javascript itself can
be very secure, if it exposes to the script only a well defined subset of
accessible objects, and methods (possibly making some properties only
read-only or causing exceptions to the specified script, ignoring attempts
to change their exposed value, or hiding the effective background value
really used). All media objects, even the most basic image (including
embedded images using a "data:" URI scheme) have security (and privacy)
concerns, just like any content types. Javascript always runs within a
predefined context that the instanciated renderer will prepare before
executing the specified script. There is no doubt that it can be extremely
powerful, and implementers already know that the preparation of this
execution context is the critical point.

Anyway, even a very basic MediaAccess API would only expose very basic
properties with simple types of values. The property associated to the
<url> would be exposed as an Url object (exposing methods needed to parse
an URL change parts of it, and then expose the resulting full <url> just
like what is done today). The Media Fragment specifiers would be exposed in
the media access API also using basic properties as well. But the Media
Access API should be compatible with both a client-side resolution (using
MF) and server-side resolution (using GET and POST methods for example) and
which method will of servicing the image will remain a task being performed
by the MediaAccess API implementation.

Some of these implementations will include things like WMS servers and
client-side layers like OpenLayers (used in cartography, with their own
internal API which does not need to be exposed by the MediaAccess API
itself, or that may be exposed via an implementation of the API in
Javascript, HTML, and so on).

All this abstraction is generic enough to be shared between HTML's <image/>
and <video/> objects, and with CSS's background images. They should be
consistant with equal capabilities.

HTML supports also other dynamic objects that may render an image and may
also include active scripted properties: <object/>, <iframe/> (and legacy
<applet/> and <embed/>, or newer <svg/>. In fact almost all HTML elements
can be scripted by custom events so the security of Javascript execution
environments is really not a new problem, we have now good models to
address this (and specifications, including in ECMAscript specifications,
which are much more precise than the historical Javascript specs, for
creating a secure "sandboxing" isolation environment, and in the more
precise definition of security domain spaces/realms).

Today most of the Internet would be almost unusable without Javascript, but
there are still many ways to add more restrictions and isolation rules
without changing the languages : almost each time you just have to track
and keep the source identified and maintain it in its initial security
realm, and permitting security domains to be bypassed only through a
sandboxing layer that will check the security certificates and all
parameters given to the API methods exposed by the sandbox).



2012/11/13 Tab Atkins Jr. <jackalmage@gmail.com>

> On Tue, Nov 13, 2012 at 2:26 PM, Philippe Verdy <verdy_p@wanadoo.fr>
> wrote:
> > No because fragments in HTML pages have a very different meaning, they
> are
> > definitely not media fragments as defined in the MF specs, they are
> > identifiers found in the parsed HTML content and used through the DOM
> API.
> >
> > The MF specs and HTML spaces are immediately incompatible without an
> > adaptation layer that transforms an HTML content into a media (image or
> > video to provide it *additional* 2D positional properties with a document
> > container). But both use a base <url> and generate their own set of
> > "fragment" identifiers.
>
> Or HTML defining that fragments of the form that MF uses are Media
> Fragments, not ID frags.  This is what SVG is doing, for example.
>
> ~TJ
>