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

I can give some examples where the <url> will definitely not be compatible
with the MF spec :

 * the case of the "javascript:" URI scheme, which could be used to
encapsulate also a script that will select a media server, request a media,
perform some authorizations, instruct it with rendering options including
linear transforms, and then instruct it it play the media and return the
MediaAccess object created by this script.

 * the case where the <url> will be that of on HTML page (including the
HTML page that could be returned by a media server instead of the image,
e.g. a "404 Not found" page, or a 5xx server error page) : the content
returned will not match the expected media type, but there will still be a
MediaAccess object returned which allows rendering it with a client-side
renderer (not necessarily impelmented by CSS itself, but searched by CSS
engines within a list of preregistered content-type renderers : a web
browser for example may register itself as if it was a media server, it
will build a virtual "image" usable as a CSS background, and it will be
able to reply to methods offered by the MediaAccess API (including
transforms and cropping).

On the other side, the CSS spec may offer a view in its own language of
this MediaAccess API :
instead of just using:

  url(<url>)
or
  image(<url-interpreted with MF>)

it would define something like

   media(<url> type(image/png) transform(...) xywh(10 10 90 90)
lang(fr;en=0.5) range(5s 10s) play())

using in this language the properties (and a few possible methods) exposed
by the MediaAccess API.

Then nothing forbids the MediaAccess API to specify that the url(<url>)
will be interpreted by default (if other MediaAccess properties or methods
are not specified, the only required property being the opaque <url>) as in
the MF specifications.


2012/11/13 Philippe Verdy <verdy_p@wanadoo.fr>

> 2012/11/13 Tab Atkins Jr. <jackalmage@gmail.com>
>
>> On Fri, Nov 9, 2012 at 6:30 PM, Philippe Verdy <verdy_p@wanadoo.fr>
>> wrote:
>> > 2012/11/9 Tab Atkins Jr. <jackalmage@gmail.com>:
>> >> I suggest sending this feedback to the Media Fragments WG, then.  I'd
>> >> prefer not to add an explicit fragment syntax to CSS unless/until we
>> >> determine that MF is broken and won't be fixed in a reasonable
>> >> timeframe.
>> >
>> > The CSS WG is concerned only because it makes a direct reference to
>> > the MF just because of the presence of a fragment identifier, without
>> > even knowing if that URL is referencing a media and where to locate
>> > it.
>>
>> This feedback is still appropriate for Media Fragment WG, not us.
>>
>
> Visibly you did not read and understood anything.
>
>  > Bote that your definition just makes a mere use of the <uri>
>> > definition, which is completely blind to document content-types (which
>> > may also not be specified by the target of this URI).
>> >
>> > A glue is missing, and in fact this suggests developping a common
>> > Media Access API, that both the CSS specification and the MF WG would
>> > reference. For now the only existing glue is the URI, it is clearly
>> > NOT enough. An URI does NOT have by itself the properties of a media.
>> > You need something to create a reference to a media (this exists in
>> > HTML with the <image/> or <video/> element, and HTML could also make
>> > use of this common Media Access API, where the URI is ONLY one of the
>> > necessary properties and methods to support).
>>
>> In CSS, the context in which you encounter the <url> is sufficient to
>> establish the same information.
>>
>
> Visibly you did not read and understood anything. You completely missed
> the point that an URI does NOT by itself establishes the fact that it has
> the properties of a meda. Which means that there's no formal way to adress
> it with the MF WG, because there's absolutely NO glue in an <url> alone to
> allow interpreting the url fragment.
>
>
>> > The MF just conscentrates on defining a specific encapsulation scheme
>> > wihin some classes of URI, it does not say that this is the proper way
>> > to reference the document containing them, that an HTML browser would
>> > first need to know how to load and cache, preferably by using the
>> > common API, rather than by trying to download the URI itself.) The URI
>> > for downloading the image from within a source is not in the scope of
>> > the MF WG (and it may need to another layer of encapsulation of the MF
>> > URI).
>> >
>> > Do you see my point ?
>>
>> This should be addressed to the Media Fragments WG.
>>
>
> No, no, no. The MF WG is definitely not concerned by how the CSS WG will
> integrate its specification in CSS. The CSS specs should define a more
> formal interface than a mere (compeltely opaque) <url>, with a "media
> objet" layer exposing an API to CSS applications.
>
> This is clearly NOT the job of the MF WG to define this integration in
> CSS, even if both WG can work on a common API for accessing "Media
> Objects", for which the <url> is ONLY ONE of the exposed properties, but
> which remains opaque.
>
> The MF WG just works on a very tiny part of this, by proposing ony a
> possible but extremely limited encapsulation scheme (there are others,
> including the integration with server-side requests, instead of just the
> client-side in the very basic MF).
>
> Not like the the exposed dimensional, positional and time properties, or
> the playable properties of such objects, which would be more useful to
> build derived <url> according to the MF specs).
>
> In my opinion, the CSS specs **MUST** be completely opaque about what is
> the <url> specified, and MUST NOT reference the MF specs for this. But it
> should reference a common API used as a more solid interface layer shared
> with other specifications for other tools (including media players that
> don't use CSS directly).
>
> This is justified because CSS absolutely does NOT need itself the <url>,
> but needs more precise and separated properties (notably dimensional for
> computing a layout and performing some basic linear transforms such
> as: zooming/scaling possibly enhanced by using alternate streams for
> efficiency, rotation, mirroring, cropping, and adaptation of color schemes
> or precision to match the color scheme and rendering intent used in the CSS
> colors and accessibility modules).
>
> I also think that several (if not many) other WG (including the HTML5 WG)
> will be concerned by the definition of this common "Media Access API" (even
> if there are for now a basic subset of methods, i.e. a minimum interface to
> support for CSS and probably HTML, but NOT a concrete implementation like
> what the MF WG currently does).
>
> This minimum API does should not require the control of media playing (by
> default it may remain unspecified if the media will be played or if just a
> single frame will be shown, but the Accessibility WG may have other
> opinions about this): the absolute minimum would be to be able to retrieve
> the 2D size of the media object, and setting its source <url> property, a
> more extended version will support setting the positional properties
> currently defined in the MF WG (x,y,w,h), and time range, possibly extended
> to support also a linear transform on which the (x,y,w,h) cropping
> logically operates.
>
> (It will be complicated by the recent development of "3D-enhanced" medias
> or versions of the media perceived from different kinds of observers, when
> working in a linear 4D space with a final 2D projection to produce the
> 3D-to-2D perspective effect) and the existance of "alternate" versions of a
> media (e.g. selection of language, and getting the list of supported
> languages, which may be other properties of the Media Access object).
>
>