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

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).