headers
Patrick Garies | 1 Sep 2009 06:40
Picon

Re: Image sprites use cases

On 8/31/2009 7:15 AM, Boris Zbarsky wrote:
> Patrick Garies wrote:
>> Yeah, it would be nice to have a compression package that carries a
>> batch of images and allows you to address them individually in a form
>> like "images.zip#image1.png"; that way, you get another layer of
>> compression, one request, and you don't have to calculate or specify
>> region information.
>
> Actually, the proposal would be a package with a manifest, then you
> address the images normally and they get loaded from the package in
> browsers that support it (and one by one from the web server in ones
> that don't). That way it's even backwards compatible and can be rolled
> out as soon as desired. See http://limi.net/articles/resource-packages
> for a very initial proposal draft; comments welcome.

I think that that proposal would indeed be better since it doesn't 
require a different addressing method and falls back well.

However:

* I'm a bit curious why it lists the MIME type as application/x-gzip; 
apparently, that's the MIME type for GZIP with a file extension of *.gz 
whereas the MIME type for ZIP is application/zip or multipart/mixed 
(although I don't know how up-to-date those ZIP types are since the IANA 
and IETF sources are from '93 and '96, respectively). Even if browsers 
don't support those types yet (which is the case if I'm reading the 
draft spec correctly), presumably support for that could be added though.

* I'm also curious if a format like *.7z would also work since it 
compresses way better than ZIP does. Unfortunately, I don't know if you
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mikko Rantalainen | 1 Sep 2009 13:26
Favicon
Gravatar

Re: Image sprites use cases

Patrick Garies wrote:
> On 8/31/2009 7:15 AM, Boris Zbarsky wrote:
>> Actually, the proposal would be a package with a manifest, then you
>> address the images normally and they get loaded from the package in
>> browsers that support it (and one by one from the web server in ones
>> that don't). That way it's even backwards compatible and can be rolled
>> out as soon as desired. See http://limi.net/articles/resource-packages
>> for a very initial proposal draft; comments welcome.
> 
> I think that that proposal would indeed be better since it doesn't
> require a different addressing method and falls back well.
> 
> However:
> 
> * I'm a bit curious why it lists the MIME type as application/x-gzip;
> apparently, that's the MIME type for GZIP with a file extension of *.gz
> whereas the MIME type for ZIP is application/zip or multipart/mixed
> (although I don't know how up-to-date those ZIP types are since the IANA
> and IETF sources are from '93 and '96, respectively). Even if browsers
> don't support those types yet (which is the case if I'm reading the
> draft spec correctly), presumably support for that could be added though.

I agree. The MIME type is obviously incorrect for ZIP archive.

> * I'm also curious if a format like *.7z would also work since it
> compresses way better than ZIP does. Unfortunately, I don't know if you
> can read and extract individual files from that format.
> 
> * I'm not sure how "already supported by browsers" is a "very desirable
> trait". Can browsers actually open ZIP files or are these just passed to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boris Zbarsky | 1 Sep 2009 14:36
Picon
Favicon

Re: Image sprites use cases

Patrick Garies wrote:
> * I'm a bit curious why it lists the MIME type as application/x-gzip; 

Looks like just a mistake.  I did say it's a very early draft, right?  ;)

> * I'm also curious if a format like *.7z would also work since it 
> compresses way better than ZIP does. Unfortunately, I don't know if you 
> can read and extract individual files from that format.

I don't either, and in general the toolchain support is spottier.  In 
particular, it involves finding a compression utility that can create 
.7z files on the part of the author.  zip has the benefit that support 
is pretty much ubiquitous.

> * I'm not sure how "already supported by browsers" is a "very desirable 
> trait".

I suspect mostly in the sense that it's more slightly clear that that 
there aren't implementation concerns like patent problems or inability 
to implement in a web browser period.  But I didn't write this proposal, 
so this is just my guess based on a 15-minute conversation with the 
author and the proposal itself.

> Can browsers actually open ZIP files

All Gecko-based browsers can, at least.

> Even if so, how does that make it better than any 
> other format aside from decreasing implementation effort (or is this the 
> key trait)?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 1 Sep 2009 14:42
Picon
Favicon

Re: Image sprites use cases

Mikko Rantalainen wrote:
> I agree that "already supported by browsers" does not count that much
> because although some browsers have native ZIP archive support (through
> jar: URL scheme) they still would not support the resource-package
> specification without changes.

Yes, indeed.

> Major issues with ZIP (listed in the article as well):
> 	* no way to specify content-type (incl. charset)
> 	* no resource specific expiry time

Right.  On the other hand, I believe every off-the-shelf archiving 
format other than multipart MIME types has the former problem, and every 
single one has the latter problem, right?

For the image use case, I should note, the type thing is a non-issue: 
browsers don't use any part of the Content-Type header for images (MIME 
type is sniffed, and charset is not relevant).  For CSS and script it's 
a problem, as the proposal notes; it's not clear whether it's enough of 
one to matter.  In practice, authors almost never set the charset on 
such resources anyway, especially in the case of scripts.  For CSS 
there's  <at> charset.  For all cases, there is the possibility of a bit of 
additional complexity in the form of a manifest file with metainformation...

> The article also mentions that ZIP archives have the index at the end of
> the file which I believe is correct. If you cannot access the end of the
> file, you cannot extract any given file inside it. As a result, no
> incremental downloads from inside the resource package.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 1 Sep 2009 15:14
Picon
Favicon

Re: [CSS21] display:run-in clarifications

Boris Zbarsky wrote:
> Makes the [1] reference a little confusing, but other than that, looks 
> good.

I was making notes to myself on implementing this stuff, and found 
another possible ambiguity.  If an element with display:run-in has an 
absolutely positioned or floated child, and gets run in, what is the 
right containing block for the child?  Is it the nearest block parent 
the run-in used to have?  Or the block the run-in ran into?

Testcase:

<!DOCTYPE html>
<html>
<body>
   <div style="padding: 100px; border: 1px solid green; position: relative">
     <span style="display:run-in; border: 1px solid red">
       <div style="position: absolute; top: 0; left: 0">aaa</div>
       bbb
       <div style="float: left">ccc</div>
     </span>
     <div style="position: relative; border: 1px solid black">
     </div>
   </div>
</body>
</html>

In Opera and IE8, the run-in just doesn't run in, as I recall.  I can't 
make sense of what webkit is doing; all the text except "aaa" disappears 
here.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Aryeh Gregor | 1 Sep 2009 16:36
Picon

Re: Image sprites use cases

On Tue, Sep 1, 2009 at 12:40 AM, Patrick Garies<pgaries <at> fastmail.us> wrote:
> * I'm also curious if a format like *.7z would also work since it compresses
> way better than ZIP does. Unfortunately, I don't know if you can read and
> extract individual files from that format.

Supporting ZIP would be great just because authors can so easily
create it, no special tools needed.  If an *additional* format like
7-Zip with better compression were supported, that would be nice too,
if the decompression time remains acceptable even on very low-end
hardware (e.g., cell phones).  .tar.bzip2 is the other obvious choice.

> * Of course, there's also the million dollar question: What is the
> likelihood that a browser vendor would implement such a thing?

That's what this list is meant to determine.  :)  This particular
scheme seems more suited to discussion by the HTML WG, though -- I
imagine it could still be added to HTML 5 at this point if there were
enough support by implementors.

On Tue, Sep 1, 2009 at 8:42 AM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
> Of course if there's a better compression format more amenable to
> use here, that would be nice too.  I'm not sure there's an obvious
> candidate.

I don't think Windows supports the creation of any compressed archive
format out of the box except ZIP.  At least not as of XP.  On the
other hand, it's not the *end* of the world if Windows authors have to
download a free third-party tool like 7-Zip to create the archive.
7-Zip can create things like .tar.gz and .tar.bz2 as well as .7z,
IIRC, and so can plenty of others.  Windows users are used to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tab Atkins Jr. | 1 Sep 2009 16:50
Picon
Gravatar

Re: [CSS21] display:run-in clarifications

On Tue, Sep 1, 2009 at 8:14 AM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
> Boris Zbarsky wrote:
>>
>> Makes the [1] reference a little confusing, but other than that, looks
>> good.
>
> I was making notes to myself on implementing this stuff, and found another
> possible ambiguity.  If an element with display:run-in has an absolutely
> positioned or floated child, and gets run in, what is the right containing
> block for the child?  Is it the nearest block parent the run-in used to
> have?  Or the block the run-in ran into?
>
> Testcase:
>
> <!DOCTYPE html>
> <html>
> <body>
>  <div style="padding: 100px; border: 1px solid green; position: relative">
>    <span style="display:run-in; border: 1px solid red">
>      <div style="position: absolute; top: 0; left: 0">aaa</div>
>      bbb
>      <div style="float: left">ccc</div>
>    </span>
>    <div style="position: relative; border: 1px solid black">
>    </div>
>  </div>
> </body>
> </html>
>
> In Opera and IE8, the run-in just doesn't run in, as I recall.  I can't make
(Continue reading)

Permalink | Reply | 3 comments |
headers
Boris Zbarsky | 1 Sep 2009 17:16
Picon
Favicon

Re: [CSS21] display:run-in clarifications

Tab Atkins Jr. wrote:
> On Tue, Sep 1, 2009 at 8:14 AM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
>> <!DOCTYPE html>
>> <html>
>> <body>
>>  <div style="padding: 100px; border: 1px solid green; position: relative">
>>    <span style="display:run-in; border: 1px solid red">
>>      <div style="position: absolute; top: 0; left: 0">aaa</div>
>>      bbb
>>      <div style="float: left">ccc</div>
>>    </span>
>>    <div style="position: relative; border: 1px solid black">
>>    </div>
>>  </div>
>> </body>
>> </html>

> I dunno if it's covered, but since inlines can't be containers for
> abspos elements

Sure they can.  They just have to be rel pos.  But that's not relevant 
here.  The question is whether the divs containing "aaa" and "ccc" in 
the testcase above have the div with black border as the containing 
block or the div with green border.  I'd personally prefer black border.

-Boris
Permalink | Reply | 2 comments |
headers
Tab Atkins Jr. | 1 Sep 2009 17:22
Picon
Gravatar

Re: [CSS21] display:run-in clarifications

On Tue, Sep 1, 2009 at 10:16 AM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>> On Tue, Sep 1, 2009 at 8:14 AM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
>>>
>>> <!DOCTYPE html>
>>> <html>
>>> <body>
>>>  <div style="padding: 100px; border: 1px solid green; position:
>>> relative">
>>>   <span style="display:run-in; border: 1px solid red">
>>>     <div style="position: absolute; top: 0; left: 0">aaa</div>
>>>     bbb
>>>     <div style="float: left">ccc</div>
>>>   </span>
>>>   <div style="position: relative; border: 1px solid black">
>>>   </div>
>>>  </div>
>>> </body>
>>> </html>
>
>> I dunno if it's covered, but since inlines can't be containers for
>> abspos elements
>
> Sure they can.  They just have to be rel pos.

::headdesk::  Duh.  Sorry, just now getting my morning caffeine.

> But that's not relevant here.
>  The question is whether the divs containing "aaa" and "ccc" in the testcase
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tab Atkins Jr. | 1 Sep 2009 17:49
Picon
Gravatar

Re: [CSS21] display:run-in clarifications

On Tue, Sep 1, 2009 at 10:22 AM, Tab Atkins Jr.<jackalmage <at> gmail.com> wrote:
> Presumably both.  They're still children of the green-border box, so
> they'd be contained by that if it was relpos.  But it definitely makes
> sense for them to treat the black-border box as their grandparent for
> purposes of containment otherwise.  I think for CSS purposes it should
> be indistinguishable from simply specifying the green-border box as an
> inline child of the black-border box to begin with.

Replace any references to "green" in the above with "red".

(Sorry, Boris!)

~TJ
Permalink | Reply | 0 comments |

Gmane