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

2012/11/9 Tab Atkins Jr. <jackalmage@gmail.com>:
> CSS did not define that fragment syntax.  As the spec explains and
> links, it is defined by the Media Fragments spec:
> http://www.w3.org/TR/media-frags/

And this syntax is ugly, and does not work with all resource URI
(notably not when they need to indicate their fragments in a way that
will conflict with this spec, notably with archives and containers
(which most often are not carrying the media-types of each one of
their contents). e.g. ZIP files (JAR's are ZIP files containing a
specification for storing their associated metadata).

As this spec is restricted to contents that are **already** identified
as media types, how can you specify this identification ? And how do
you resolve the conflicts between the interpretations of the fragment
identifiers ?

Note that section 3.2 (Resolving URI fragments within the user agent)
creates conflicts of interpretation immediately because it interacts
directly on the retrieval process for the resource. If t's an HTTP of
file resource, it wouf be restricted to speify only byte offsets,
something not usable with media types. The other solution would be
that the media-object is first contructed but not retrieved, and the
UA then interacts with it in say what to look for, then the
media-object performs itself the retrieval from the given URL, trying
to locate the fragment as preceisely as possible (this is backward
processing) but for this there's still the need for locatin in the
full URI. where to start parsing the fragment (beacuse you won't know
that this URL is the URL of a media fragment before nowing that the
document at the base address is a media (for this you need to query
some minmum info about it to know what kind of content it is. If you
start downloading the content, how can you limit it and where to start
downloading it ?

All this seems very ugly. Additionally media files are also structured
by themselves: things to consider are: selection of a rendering
format, selection of audio and video channels and quality, selection
of language. Each channel defines its own positional system (they are
not always synchronized between each other, and not always of the same
type along the time or space, with multimedia containers).

It is the presence of complex container envelops that span more
relations than just space and time, which makes this spec very
minimalist.

In addition this spec is still NOT implemented in almost all browsers.
The exeriments that have been performed on this are all full of bugs
(including serious security ones, with things that have been forgotten
in the specification at the API level for media objects to support
SAFELY the selection and extraction of fragments, which may not have
all the same security requirements as the container itself, notably
beause some parts may be encrypted).

Received on Friday, 9 November 2012 00:08:22 UTC