Re: Background image cropping

On Jun 10, 2014, at 8:16 AM, Marat Tanalin <mtanalin@yandex.ru> wrote:

> 10.06.2014, 18:44, "Dirk Schulze" <dschulze@adobe.com>:
>> I believe Mozilla has a -moz-image-rect() [1] image function that clips the input image argument. It is not specified though.
>> 
>> Dirk
>> 
>> [1] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-image-rect
> 
> By the way, Mozilla's `-moz-image-rect()` functional notation looks much better than Media Fragments in CSS for several reasons:
> 
>    * Media Fragments spec unreasonably tries to reuse anchor/hash
>      part of the URL for something that has _nothing to do_ with
>      anchor/hash and therefore is potentially confusing;

Why is it unreasonable? The definition of a fragment - what you call the anchor/hash - in RFC 3986 [1]  says:

"The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information."

No more, no less. URI fragments were not meant only for page anchoring. Page anchors are just one use-case of this pattern today, albeit the most common one. 

[1] http://www.ietf.org/rfc/rfc3986.txt

Second, why should CSS be *required* to retrieve a video frame or an image fragment? Why shouldn't I be able to share a link to a fragment? If your page shows a single video frame and I right-click/copy-link, it would a very poor user experience for the recipient of this link to find themselves downloading the whole video instead. 

Third, another goal afaik is to make it possible to retrieve a specific fragment without downloading the whole primary resource first, which in turn implies passing some info to the server. This suggests a URI query, a URI fragment or an HTTP header. The latter is not very user-friendly; query vs. fragment is discussed in the MF spec.

There may be other side benefits to such URIs e.g browsers may initiate resource downloads before CSS is resolved and might thus start downloading a resource before knowing how much of it they need etc.

> 
>    * functional notation looks more readable/intuitive than
>      `xywh`-like stuff used in Media Fragments;
> 
>    * functional notation looks more flexible as for ability to mix
>      different units for different dimensions and also to use `calc()`
>      function for a single dimension value.

Yes, I agree the readability and usability of a URI fragment are poor. A functional notation that would result in the client requesting the image using the corresponding media fragment URI sounds interesting. As long as it does not result in the kind of poor user experience described above. 


> 
> Since there are no implementations of Media Fragments in CSS, it may make sense to drop trying to apply Media Fragments to CSS in favor of a functional notation similar to `-moz-image-rect()`.
> 
> Thanks.
>

Received on Tuesday, 10 June 2014 15:58:54 UTC