Re: [whatwg] Placeholder option for text input boxes

[Russell Leggett]

I've wrestled with this because its something that our designer has wanted
to use all over the place for an application I'm working on. It turns out to
be a usability nightmare if not used sparingly. When we used it, it was
definitely in place of an actual label, and I think this would be true in
most cases. In the cases where an outer label and a placeholder are needed,
I think the solution could just be to have two Label elements that point to
the same input.
>From the HTML 4.01
spec
 :

> More than one 
> LABEL may
> be associated with the same control by creating multiple references via the
> for  attribute.
>

Then CSS could be used on one of the labels to make it appear as placeholder
content.

On Thu, Oct 2, 2008 at 7:34 PM, Tab Atkins Jr. <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine <[EMAIL PROTECTED]>wrote:
>
>> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle <[EMAIL PROTECTED]> wrote:
>> [snip]
>> > 4)  (moving label textual content into  as placeholder
>> text; currently with Javascript to mutate the DOM, in the > future with CSS
>> to present the desired appearance while keeping the DOM stable)
>> >  Pro: Most semantic.
>> [snip]
>>
>> That depends on what you are using it for. What if you are using it to
>> apply a placeholder that says "(optional)"? That is not a label at all.
>> There are a lot of uses for the proposed placeholder attribute that just
>> don't fit into any of the other categories. I think a placeholder attribute
>> would be great.
>
>
> Hmm, true.  That's definitely a case where the text can't be argued to be a
> label.
>
> Of course, it's still not in any way semantic.  The only difference between
> "(optional)" being displayed near the input and being displayed *within* the
> input is one of aesthetics.   The meaning of the document isn't changed one
> iota.  This leans me even more toward a CSS solution.  I'll just bite the
> bullet and bring it up to the CSS WG.
>
> ~TJ
>

Re: [whatwg] A slightly different use-case for shared workers

[Russell Leggett]

I'm also a Pandora fan, and I actually thought of another use. In addition
to popping out a separate player, Pandora also opens new tabs/windows to
browse pages about artists/songs. These pages allow you to listen to
samples, but listening to them does not pause the player. It would be pretty
cool to use a shared worker to be able to tell the main player to pause if
another window plays a sample and then resume when the sample completes. I
don't know if this example actually contributes to the discussion, but it
seemed like a cool idea :)

On Fri, Aug 29, 2008 at 10:20 AM, Cameron McCormack <[EMAIL PROTECTED]> wrote:

> Robert O'Callahan:
> > Why not just open new window and move the playing  element from
> the
> > old window into the new window? You might need to call play() on it again
> in
> > the new window, but you shouldn't lose your place in the stream.
>
> Why shouldn't that throw a WRONG_DOCUMENT_ERR?
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
>

Re: [whatwg] Ghosts from the past and the semantic Web

[Russell Leggett]

I actually think that using custom microformat-like conventions with classes
or tags is really not as robust a solution as what is being attempted with
RDFa (I honestly did not know much about RDFa before this conversation).
However, while people keep suggesting classes, I have yet to hear anyone
suggest the data- attributes. Maybe it was said or implied elsewhere, but it
seems like a good fit here. Instead of requiring the addition of "about" or
"property" attributes, just use "data-about" or "data-property". It may not
be ideal, but it fits with the existing spec.
Beyond that, you have the issue of CURIEs. I can see how they make a good
fit, but it really is just piggybacking on  something else convenient. It's
an abuse of namespace syntax. That works fine for XHTML, but there is no way
you are getting namespaces put into HTML, so figure out another way. Why not
something like "data-curie="dc:http://purl.org/dc/elements/1.1/";? It may not
be as easily accessible to the parser as a namespace prefix, but remember
that this is seriously all convention anyway. At least this convention has
less interference, and gets closer to what you want.

On Thu, Aug 28, 2008 at 5:32 AM, Henri Sivonen <[EMAIL PROTECTED]> wrote:

> On Aug 28, 2008, at 05:59, Ben Adida wrote:
>
>  Same goes with MySpace widgets. Paste one thing, get the widget. Who's
>> going to go paste two things in two different places? It's really
>> important to make HTML the carrier of this information.
>>
>
>
> It seems to me that this line of reasoning should lead to using identifiers
> that are contained in one string instead of splitting identifiers and
> putting the pieces in two places like CURIEs do.
>
> (In fact, the declaration part of CURIE syntax has already been forgotten
> in examples sent to this mailing list.)
>
> --
> Henri Sivonen
> [EMAIL PROTECTED]
> http://hsivonen.iki.fi/
>
>
>

Re: [whatwg] Joined blocks

[Russell Leggett]

Ignore my last statement. It was a draft I wrote before reading Ian's
response. If he has something in mind to get the same thing accomplished
without adding extra tags, all the better.

On Sat, Aug 2, 2008 at 8:06 PM, Russell Leggett
<[EMAIL PROTECTED]>wrote:

> I would be happy to have this as a purely css solution, but if multiple
> container elements are required for the content to flow to, would you not
> want that relationship in the html? We specify anchors, links, and
> relationships in html, why not this? How the flow between blocks should
> certainly be controlled by css - when to break between blocks etc., but
> there a semantic and structural aspect as well.
> -Russ
>
>
> On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <[EMAIL PROTECTED]>wrote:
>
>> On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <
>> [EMAIL PROTECTED]> wrote:
>>
>>> For what it's worth, Shannon, I totally agree with you. Not only is this
>>> something I have been wanted for a long time, but I think it belongs in the
>>> html. It's one thing if you just want columns, which is being covered here:
>>> http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but
>>> there are times when the joined blocks are more remote and distinctly not
>>> columns, requiring the extra markup to control where it must join to.
>>> However, while useful for complex layouts, this is definitely the much
>>> smaller use case. I think it would make a great addition, but I suppose
>>> people have to have priorities! ;)
>>> -Russ
>>>
>>
>> This is definitely and distinctly a CSS issue, not a HTML one.  The fact
>> that the contents of an element flow into another box elsewhere in the page
>> has nothing to do with the underlying structure of the data - it's still a
>> single cohesive element, and thus in html it would be marked up exactly as
>> normal.  You just happen to be displaying it differently.
>>
>> As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of
>> dynamic columns, which will be the most common need for this sort of thing.
>> However, it's certainly reasonable that one would want more than that, to
>> allow the contents of an element to flow to an arbitrary location elsewhere
>> on the page.  I could have sworn there was a flow-to property proposed in
>> one of the working drafts, but I couldn't find it, so it's possible it only
>> existed in my fevered imagination (it's also possible I was misremembering
>> the "named flows" feature in Generated Content for Paged Media [1]).  A
>> limited form of this property exists in the Paged Media section of the
>> Template Layout module [2], where you can specify a template that spans
>> across several pages.  If the contents of a slot would overflow, it instead
>> forces a page-break within the slot and flows onto the next page, filling
>> the slot of the same name.
>>
>> I've got some ideas in this regard, but we should move it to the CSS list,
>> [EMAIL PROTECTED]
>>
>> ~TJ
>>
>> [1] http://www.w3.org/TR/css3-gcpm/#named1
>> [2] http://www.w3.org/TR/css3-layout/#templates
>>
>
>

Re: [whatwg] Joined blocks

[Russell Leggett]

I would be happy to have this as a purely css solution, but if multiple
container elements are required for the content to flow to, would you not
want that relationship in the html? We specify anchors, links, and
relationships in html, why not this? How the flow between blocks should
certainly be controlled by css - when to break between blocks etc., but
there a semantic and structural aspect as well.
-Russ

On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <[EMAIL PROTECTED]>wrote:

> On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <[EMAIL PROTECTED]
> > wrote:
>
>> For what it's worth, Shannon, I totally agree with you. Not only is this
>> something I have been wanted for a long time, but I think it belongs in the
>> html. It's one thing if you just want columns, which is being covered here:
>> http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but
>> there are times when the joined blocks are more remote and distinctly not
>> columns, requiring the extra markup to control where it must join to.
>> However, while useful for complex layouts, this is definitely the much
>> smaller use case. I think it would make a great addition, but I suppose
>> people have to have priorities! ;)
>> -Russ
>>
>
> This is definitely and distinctly a CSS issue, not a HTML one.  The fact
> that the contents of an element flow into another box elsewhere in the page
> has nothing to do with the underlying structure of the data - it's still a
> single cohesive element, and thus in html it would be marked up exactly as
> normal.  You just happen to be displaying it differently.
>
> As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of
> dynamic columns, which will be the most common need for this sort of thing.
> However, it's certainly reasonable that one would want more than that, to
> allow the contents of an element to flow to an arbitrary location elsewhere
> on the page.  I could have sworn there was a flow-to property proposed in
> one of the working drafts, but I couldn't find it, so it's possible it only
> existed in my fevered imagination (it's also possible I was misremembering
> the "named flows" feature in Generated Content for Paged Media [1]).  A
> limited form of this property exists in the Paged Media section of the
> Template Layout module [2], where you can specify a template that spans
> across several pages.  If the contents of a slot would overflow, it instead
> forces a page-break within the slot and flows onto the next page, filling
> the slot of the same name.
>
> I've got some ideas in this regard, but we should move it to the CSS list,
> [EMAIL PROTECTED]
>
> ~TJ
>
> [1] http://www.w3.org/TR/css3-gcpm/#named1
> [2] http://www.w3.org/TR/css3-layout/#templates
>

Re: [whatwg] Joined blocks

[Russell Leggett]

For what it's worth, Shannon, I totally agree with you. Not only is this
something I have been wanted for a long time, but I think it belongs in the
html. It's one thing if you just want columns, which is being covered here:
http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there
are times when the joined blocks are more remote and distinctly not columns,
requiring the extra markup to control where it must join to. However, while
useful for complex layouts, this is definitely the much smaller use case. I
think it would make a great addition, but I suppose people have to have
priorities! ;)
-Russ

On Fri, Aug 1, 2008 at 1:35 AM, Shannon <[EMAIL PROTECTED]> wrote:

>  I agree this is _mostly_ a CSS issue except that there is semantic meaning
> to the join attribute beyond layout. The attribute could serve as a guide to
> search engines, web-scrapers or WYSIWYG applications that two areas of the
> page should be considered a single piece of content. I am also unsure as to
> how this might affect other aspects of browser, javascript or DOM behaviour.
> There may be other uses or side-effects I can't imagine. At any rate CSS
> cannot associate elements so the join attribute should be considered
> independent of the style considerations as a means of saying "this block
> follows that one". Nonetheless I will do as you suggest.
>
> Shannon
>
>
> Ian Hickson wrote:
>
> On Fri, 1 Aug 2008, Shannon wrote:
>
>
>  Something I think is really missing from HTML is "linked text" (in the
> traditional desktop publishing sense), where two or more text boxes are
> joined so that content overflows the first into the second and
> subsequent boxes. This is a standard process for practically all
> multi-column magazines, books and news layouts. It is especially
> valuable for column layouts where the information is dynamic and
> variable in length and therefore cannot be manually balanced. This is
> not something that can be solved server-side since the actual flow is
> dependent on user style-sheets, viewport and font-size.
>
>
>  I agree that this would be a useful feature for the Web platform. However,
> I believe the CSS working group is a better venue for exploring such
> options. I recommend forwarding your proposal to [EMAIL PROTECTED]
>
>
>
>
>

Re: [whatwg] Application deployment

[Russell Leggett]

>
> Please explain why you consider concatenating JavaScript sources dirty.
>

I don't necessarily think it's dirty, but any choices that game the system
for purely performance reasons seem hackish to me. Concatenating js files
for performance reasons is certainly less offensive than css sprites, but it
still begs the question: is this always the right choice. For example, let's
say I'm using jQuery plus a few plugins. The resources are really separate
entities from third parties. Should I have to concatenate them?

That said, there is clearly not much interest for this proposal here.
I graciously concede :)

-Russ

On Wed, Jul 30, 2008 at 2:43 PM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  Please explain why you consider concatenating JavaScript sources dirty.
>  You can have a library of all JavaScript definitions relevant to your site
> in one source file and I am not sure what is wrong with it, except that a
> library should consist of books, but that concept was already broken long
> ago.
>
> Chris
>
>
>  --
>
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Russell Leggett
> *Sent:* Wednesday, July 30, 2008 4:25 PM
> *To:* Peter Kasting
> *Cc:* [EMAIL PROTECTED]
> *Subject:* Re: [whatwg] Application deployment
>
>
>
> It seems to me that many of the additions to the HTML spec are there
> because they provide a standard way to do something we are already doing
> with a hack or more complicated means. CSS sprites are clearly a hack.
> Concatenating js files are clearly a hack. Serving from
> multiple sub-domains to beat the connection limit is also a workaround. My
> proposal is intended to approach the deployment issue directly, because I
> think it is a limitation in the html spec itself and therefore, I think the
> html spec should provide its own solution. My proposal may not be the best
> way, but assuming the issue will be dealt with eventually by some other
> party through some other means does not seem right either.
>
>
>

Re: [whatwg] Proposal for a link attribute to replace

[Russell Leggett]

What about an alternative attribute like "navigate" instead of "href". It
would not carry the full weight of the anchor tag, but would handle the 90%
use case. It would not allow for the same options as the a tag, and the a
tag would continue to work the same way that it has been.

On Wed, Jul 30, 2008 at 10:45 AM, Smylers <[EMAIL PROTECTED]> wrote:

> Ian Hickson writes:
>
> > ... global href="" attribute for all elements ... Unfortunately, I've
> > been told over and over by implementers that a global href="" is a bad
> > idea
>
> Noted.
>
> However:
>
> > > onclick="this.getElementsByTagName('a')[0].click()">
> >
> > > onclick="location = this.getElementsByTagName('a')[0]">
> >
> > On Thu, 29 May 2008, Frank Hellenkamp wrote:
> >
> > > In the best case the whole rectangle of the teaser is clickable. At the
> > > moment you need some javascript or an a-tag with "display: block" for
> > > it, to get this behavior (see example in my last mail).
> >
> > I don't think the JS is a big deal.
>
> Compared to , using onlick events generally provides a
> worse user experience, such as the status bar not being updated to
> indicate a link's destination in advance of committing to navigate
> there.
>
> It may be, given implementers' requirements, that JavaScript solutions
> like the above are the best we can do.  But let's not pretend they are
> as good as links that don't involve scripting.
>
> Smylers
>

Re: [whatwg] Application deployment

[Russell Leggett]

>
> The only thing archives get you IMO is difficulty with caching algorithms,
> annoyances rewriting URLs, potentially blocked parsing, and possibly
> inefficient use of network bandwidth due to reduced parallelization.
>

I don't see any reason that parsing would need to be blocked any more than
it already is. No rewriting of URLs would be necessary at all, and I have
already provided suggestions for simple solutions that would prevent
unnecessary blocking.

Server sharding and higher connection limits solve the problem of
> artificially low connection limits.  JS script references block further
> parsing in most browsers; the correct solution to this, as Ian said, seems
> like some variant of Safari's optimistic parser.  Referencing large numbers
> of tiny images causes excessive image header bytes + TCP connection overhead
> that can be reduced or eliminated with CSS spriting.


Server sharding and CSS sprites are both artificial solutions that are used
to deal with limitations of the existing deployment model. If you are
worried about fragility, look no further than css sprites. They have to be
background images, and require precise measurement of size and location.
This creates extremely tight coupling between the css code and the file
itself. Not to mention the maintenance of the sprite images themselves.
Clearly we are already dealing with the problems of resource loading and how
to make it most efficient. Our existing solutions are widely varied and
complex, but all of them result in changes to our html/css/js code that
would not already be there if we did not have that limitation.

It seems to me that many of the additions to the HTML spec are there because
they provide a standard way to do something we are already doing with a hack
or more complicated means. CSS sprites are clearly a hack. Concatenating js
files are clearly a hack. Serving from multiple sub-domains to beat the
connection limit is also a workaround. My proposal is intended to approach
the deployment issue directly, because I think it is a limitation in the
html spec itself and therefore, I think the html spec should provide its own
solution. My proposal may not be the best way, but assuming the issue will
be dealt with eventually by some other party through some other means does
not seem right either.

-Russ


On Wed, Jul 30, 2008 at 4:27 AM, Peter Kasting <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 29, 2008 at 5:10 PM, Russell Leggett <
> [EMAIL PROTECTED]> wrote:
>
>>  That is a performance killer.
>>
>>
>> I don't think it is as much of a performance killer as you say it is.
>> Correct me if I'm wrong, but the standard connection limit is two.
>>
>
> The standard connection limit is 6, not 2, as of IE 8 and Fx 3.  I would be
> very surprised if this came back down or was not adopted by all other
> browser makers over the next year or two.
>
> Furthermore, the connection limit applies only to resources off one host.
>  Sites have for years gotten around this by sharding across hosts (
> img1.foo.com, img2.foo.com, ...).
>
> There are many reasons resources can cause slowdown on the web, but I don't
> view this "archive" proposal as useful in solving them compared to existing
> tactics.  Server sharding and higher connection limits solve the problem of
> artificially low connection limits.  JS script references block further
> parsing in most browsers; the correct solution to this, as Ian said, seems
> like some variant of Safari's optimistic parser.  Referencing large numbers
> of tiny images causes excessive image header bytes + TCP connection overhead
> that can be reduced or eliminated with CSS spriting.
>
> The only thing archives get you IMO is difficulty with caching algorithms,
> annoyances rewriting URLs, potentially blocked parsing, and possibly
> inefficient use of network bandwidth due to reduced parallelization.
>  Archives remove the flexibility of a network stack to optimize
> parallelization levels for the user's current connection type (not that I
> think today's browsers actually do such a thing, at least not well; but it
> is an area with potential gains).
>
> PK
>

Re: [whatwg] Application deployment

[Russell Leggett]

>
> That is a performance killer.


I don't think it is as much of a performance killer as you say it is.
Correct me if I'm wrong, but the standard connection limit is two. It is not
as though every external file could be loaded at once. Additionally, as I
said, you could split resources into multiple archives to take advantage of
multiple connections, because they can be loaded asynchronously without
issue.  Remember, the use case for this would be when there are likely
dozens of different files that need to be loaded.

So you get nondeterministic load behaviour anyway. This is not good.


This is not so different than directly requesting a file from multiple tabs.
Let's say page 1 and page 2 each use the same image. If I load page 2 first,
it will go directly to the server. If I load page 1 first, page 2 will get
the image from cache.

Clearly, there are other ways of performing this task, but I think this way
is simple and I know that I would gladly accept it as a possibility. It
falls within the same realm that any caching behavior does. It is meant
purely for performance, but if you are relying on it for a given behavior
then you are on a road to trouble.

The archived resources should be static, and also available as individual
files. Pre-fetching them should only be used for performance gains, and if
it would not be performant, it should not be used. However, I think there is
a fairly wide range of sites or applications that could benefit from this
feature. If there are other ways of improving it, or making it work better
for certain edge cases, that would be great, but don't throw the baby out
with the bath water.

Off the top of my head, I can think of a couple of ways to refine the
feature and deal with the issues raised.

   - Only blocking the loading of files that could logically be inside the
   archive: if the archive is located at "/js/resources.zip", then the only
   files that should be blocked would have to be located under "/js".  would not be blocked.
   - To go a step further, there could even be some kind of "pattern"
   attribute that would block the loading of files that matched a url pattern.
   For example, if the archive were located at "/", but had a pattern of
   "**.js,**.css,/images/*", only js, css, and files under the "/images"
   directory would be blocked.


On Tue, Jul 29, 2008 at 2:13 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett <
> [EMAIL PROTECTED]> wrote:
>
>> Yes, the one major hang up that I foresee is how a browser should handle
>> asynchronous loading. How would it know the contents of the archive before
>> it loaded the archive so it did not try to load the same files directly? The
>> simple answer would be to load the archive(s) synchronously.
>>
>
> That is a performance killer.
>
> As for references in a different tab, if the separate tab/document did not
>> reference the zip archive first, it would operate as normal. It would check
>> the cache and then attempt to load. If the zip had been loaded from the
>> first page already, the file would be present in the cache, and if not, then
>> the browser would attempt to retrieve it from the server.
>>
>
> So you get nondeterministic load behaviour anyway. This is not good.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Re: [whatwg] Application deployment

[Russell Leggett]

>
> So if I load 
> http://www.example.com/x.m21#y.html and
> (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.


Yes, the one major hang up that I foresee is how a browser should handle
asynchronous loading. How would it know the contents of the archive before
it loaded the archive so it did not try to load the same files directly? The
simple answer would be to load the archive(s) synchronously. In my previous
example:









The browser could begin loading the zip, and during the load wait before
loading any other files. In an effort to take advantage of multiple
connections, multiple archives could be used. Multiple archives could be
loaded asynchronously without issue.

As for references in a different tab, if the separate tab/document did not
reference the zip archive first, it would operate as normal. It would check
the cache and then attempt to load. If the zip had been loaded from the
first page already, the file would be present in the cache, and if not, then
the browser would attempt to retrieve it from the server.

My proposal is only intended as a way to make HTML work the way it was
intended and remain efficient.  CSS sprites and concatenated scripts are
assumed for any high performance site, but they add an unnecessary level of
complexity. Other suggestions such as HTTP pipelining and the jar protocol
are more complex and out of scope of the HTML5 specification. I think my
proposal degrades gracefully, and while I am not a browser manufacturer, it
seems relatively simple to implement.

Russ

On Tue, Jul 29, 2008 at 3:51 AM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote:
>
>>
>> c) that the contents of the container, once fetched and un-packed,
>> logically 'shadow' the directory where the container came from.
>>
>
> It sounds like that affects all loads, which leads to issues:
>
> So if I load 
> http://www.example.com/x.m21#y.htmland 
> (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Re: [whatwg] Application deployment

[Russell Leggett]

Although jar, mhtml, and also the widget spec have some related ideas, I
think all of them are more complex than the solution I'm suggesting as well
off target. I will give a full example.

Let's say I have a large javascript application that is broken into several
files for better organization.








This could easily be more, but you get the drift.

But let's say we could zip up all the files, and retrieve them at the start
of an html document:




This zip might contain a directory "js" and inside would contain the js
files. When the zip file was loaded with the link tag, it would immediately
be unzipped and the files would be put in the cache as though they were
loaded individually. None of the javascript or other resources would be
executed or processed, they would simply be added to the cache. Later in the
html document, these resources could be pulled from the cache.


My web app









Notice that the script tags stay the same with or without resources link. If
it was not supported, it could easily be ignored and the page would still
work. In addition to script tags, this could easily work with css and images
as well as any other resources.

On Mon, Jul 28, 2008 at 2:21 PM, Kristof Zelechovski
<[EMAIL PROTECTED]>wrote:

>  My complaint was about how the jar URL scheme wannabe conceptually
> differs from the schemes we already officially have, not about how ugly it
> is to have two consecutive colons.  It is ugly but it does not matter.  What
> matters is that a scheme is being promoted that is specific to one content
> type, just as the APPLET element is discouraged for the same reason.
> Content types and URL schemas should not be coupled because they live in
> different worlds.  The jar scheme is an exception in Java just as the
> javascript scheme is an exception in HTML because these are essential for
> the internal mechanisms of either language.  Java does not recognize the
> javascript scheme; why should HTML recognize jar?  Because Java programmers
> use it extensively?  Even if that is true, which I doubt (because I think
> there should be a more abstract API for getting application resources
> anyway, perhaps using jar in the implementation), it hardly matters for
> HTML.
>
> I think dealing with two fragment identifiers is a lesser evil than turning
> the URL upside down.
>
> The difference between a hierarchical file system and a flat file system
> are minute indeed and it is primarily related to search efficiency:
> traversing a directory tree in logical order is straightforward in HFS but
> requires a prior conversion in FFS; HFS directories are inaccessible
> (without server extensions) but FFS "directories" simply do not exist.
>
> If relative locators are allowed to go out of the jar (relative to the
> directory the jar is in) then all internal hyperlinks into the archive must
> be "#full/path#fragment" and all local links must be "##fragment".  That
> means the code base must be preprocessed before packaging.
>
> Anyway, it is not obvious at all that linking inside a packaged HTML
> application should be supported.  An alternative solution would be to
> indicate the start page in the manifest and let the code run under a fake
> root.
>
> IMHO,
>
> Chris
>  ------
>
> *From:* Adrian Sutton [mailto:[EMAIL PROTECTED]
> *Sent:* Monday, July 28, 2008 10:56 AM
> *To:* Kristof Zelechovski; Adam Barth
> *Cc:* [EMAIL PROTECTED]; Russell Leggett; Philipp Serafin
> *Subject:* Re: [whatwg] Application deployment
>
>
>
> On 28/07/2008 09:22, "Kristof Zelechovski" <[EMAIL PROTECTED]> wrote:
>
> > Having this URL monster shipped does not preclude replacing it with a
> more
> > logical one and deprecating the original one.  People make mistakes all
> the
> > time and fortunately there are cases where the harm can be undone.
>
> It's not just FireFox that supports this URL scheme - the entire Java world
> uses it and supports it back as long as JAR files have existed as far as I
> know. While web pages are a different domain it seems silly to have two
> completely different notations for the same thing just because of aesthetic
> reasons.
>
> It's also worth noting that the jar: scheme will allow you to target
> anchors
> in a HTML document that's within the archive where as the fragment
> identifier syntax would not, unless you used two fragment identifiers:
> http://www.example.com/site.jar#/path/inside/foo.html#heading1<http://www.example.com/site.jar#/path/inside/foo.html%23heading1>
>
>
> > Of course this means that the way relative locators inside an archived
> > document are handled must be changed (they should apply to the fragment
>

Re: [whatwg] Application deployment

[Russell Leggett]

Just to clarify, I wanted to point out that my suggestion is related to both
of the suggested alternatives (mhtml and the jar protocol), but is very
different in intention. I think there is a very real need in the area of
deployment for resource intensive web pages/applications. The developer has
to choose between bad performance (several http requests) or a complicated
build process (concatenating js and css and creating css sprites). And even
in the best case scenario, they still cannot be loaded together (js and css
still have to be loaded separately). The intention for my suggestion is not
that resources be accessible from inside a zip or jar, or that a whole web
site be zipped up and sent over email, I was just trying to think of an easy
way to relieve this pain point.
My thought for implementation would be something like:



Then the zip file could basically be unzipped and loaded into the browser
cache. When a link to retrieve a stylesheet, image, or script was reached,
it would just check the cache as it normally would. There would be no
special link urls or protocols.

I'm sure there are holes in the idea somewhere, but I really do think that
some solution can be found, and I think it is a large enough pain point that
it is worth addressing.

Thanks,
Russ

On Mon, Jul 28, 2008 at 5:16 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Mon, 28 Jul 2008, Adam Barth wrote:
> >
> > My guess is this mechanism will not be included in HTML 5 because some
> > of the other browser vendors have expressed their distaste for nested
> > URL schemes.
>
> I've no intention of adding jar: to HTML5, but more because it seems
> completely orthogonal to the markup language than for any other reason.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

[whatwg] Application deployment

[Russell Leggett]

Hi all,
I checked through the archives, but did not see anything, so if this has
been addressed already, I apologize.

This is a suggestion that is more helpful to larger single page web
applications, but could also be very helpful to other resource intensive web
pages. My thought is that it could be extremely helpful to create some kind
of web application deployment format. Basically, the same idea as what java
does with jars (Java ARchives). A jar is basically just a zip file with a
different extension. Inside, it contains all the resources required for that
application, including code and images.

How hard would it be to support something similar in a browser? Instead of
worrying about concatenating javascript and css files to reduce HTTP
requests, if all js,css,and even images and other files could be zipped up
or tarred, that would only require a single HTTP request. This could
basically just add the files to the browser cache or other local storage
mechanism so that requests for the resources would not need to make an extra
trip.

Thanks,
Russ