On Sat, 31 Oct 2009, Rowan Nairn wrote:
I want to provide an animated page transition that doesn't break the
back button or the URL bar and degrades gracefully in non-javascript
UAs. You can see an example of this at http://mrtaggy.com/ . This is a
site I launched last year that uses
On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson ian at hixie.ch wrote:
My recomendation would be to follow the process for adding features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
In particular the bit about experimental
Hi there,
That onlyreplace attribute is not enough, and trust me, I have
spent quite a while on solutions transforming HTML documents using
bits contained in external instances...
Hixie referenced at some point in the thread my HTMLOverlays proposal
[1] and that proposal has a clear plus
Daniel Glazman schrieb:
Hi there,
That onlyreplace attribute is not enough, and trust me, I have
spent quite a while on solutions transforming HTML documents using
bits contained in external instances...
Hixie referenced at some point in the thread my HTMLOverlays proposal
[1] and that
Looking at this (simplified) example from Markus:
html
head
title id=titleMy title/title
base onlyreplace=title
/head
body
ul id=navigation
lia href=otherpage.html onlyreplace/li
/ul
div id=contents
pText/p
div
/body
/head
Would it be
Markus Ernst wrote:
They are crucially different in some points:
- HTMLOverlays is a ready-to-use script solution. It does not require
any specification nor implementation by UAs. Instead, it requires work
on the authoring side; using HTMLOverlays means totally re-writing your
websites.
On Thu, Oct 22, 2009 at 1:56 AM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
Hi there,
That onlyreplace attribute is not enough, and trust me, I have
spent quite a while on solutions transforming HTML documents using
bits contained in external instances...
Hixie
Tab Atkins Jr. wrote:
I actually consider that a loss. It's addressing a different problem,
you see. HTMLOverlays is basically client-side includes. While you
It's client-side only because I implemented in JS that way! Explain
me what prevents from implementing server-side?
I think you
On Thu, Oct 22, 2009 at 9:47 AM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:
Tab Atkins Jr. wrote:
I actually consider that a loss. It's addressing a different problem,
you see. HTMLOverlays is basically client-side includes. While you
It's client-side only because I
2009/10/19 Schuyler Duveen wha...@graffitiweb.org:
I'm starting to think the addressability is the main constraint. What
if the original @onlyreplace anchor tag:
a onlyreplace=id1 id2 href=page2.html /
would be equivalent to something like this:
a href=#view(page2.html id1 id2) /
On Mon, Oct 19, 2009 at 5:37 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Mon, Oct 19, 2009 at 1:10 PM, Markus Ernst derer...@gmx.ch wrote:
Aryeh Gregor schrieb:
But it breaks progressive rendering, which could be extremely
annoying. The user might give up after a second or two of no
Tab Atkins Jr. schrieb:
On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Some attention needs to be given to error handling. What happens if
one or more of the requested id's aren't found? Do they silently
fail? If so, this could result in the link doing
On Mon, Oct 19, 2009 at 3:49 AM, Markus Ernst derer...@gmx.ch wrote:
What do you think about:
1. Defining which ids are to be replaced:
- The list of IDs to replace is in base tag, as described earlier in this
thread. a and form elements can have a boolean @onlyreplace attribute
that
On Mon, Oct 19, 2009 at 4:49 AM, Markus Ernst derer...@gmx.ch wrote:
- If none of the indicated IDs are found, *replace the whole page*. This
makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced
by just using different IDs.
But it breaks progressive rendering, which could
Aryeh Gregor schrieb:
On Mon, Oct 19, 2009 at 4:49 AM, Markus Ernst derer...@gmx.ch wrote:
- If none of the indicated IDs are found, *replace the whole page*. This
makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced
by just using different IDs.
But it breaks progressive
On Mon, Oct 19, 2009 at 1:10 PM, Markus Ernst derer...@gmx.ch wrote:
Aryeh Gregor schrieb:
But it breaks progressive rendering, which could be extremely
annoying. The user might give up after a second or two of no
response, as the (possibly quite long) page is fetched and parsed.
This is
On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
2009/10/17 Jonas Sicking jo...@sicking.cc:
In fact, you don't even need to use pushState. For now this can be
faked using onhashchange and fragment identifier tricks. It's
certainly not as elegant as pushState
On Fri, 16 Oct 2009, Aryeh Gregor wrote:
I'm drawn back to my original proposal. The idea would be as follows:
instead of loading the new page in place of the new one, just parse it,
extract the bit you want, plug that into the existing DOM, and throw
away the rest. More specifically,
The cruft in the hash is needed so that we know what IDs to refresh
when navigating back (which could be taken away into a JS URL-to-IDs
map), and to detect a change if the same URL is accessed several times
(that's probably overkill). Still, the point was to show it can work
today; it really
dd0fbad0910161343s277083c7v4eee5197c15bd...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Some comments:
I think an optimization that enables the server to strip unnecessary content is
a MUST.
It seems the browser will need to
On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson i...@hixie.ch wrote:
My recomendation would be to follow the process for adding features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
In particular the bit about experimental implementations.
2009/10/18 Ian Hickson i...@hixie.ch:
On Sat, 17 Oct 2009, Schuyler Duveen wrote:
One of the big issues we found using it on some other sites is that
javascript listeners (rather than onclick= attributes), and other DOM
pointers in the system became stale. Thus, only half the problem was
On Sat, Oct 17, 2009 at 2:45 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
2009/10/17 Jonas Sicking jo...@sicking.cc:
In fact, you don't even need to use pushState. For now this can be
faked using onhashchange and fragment identifier tricks. It's
certainly not as elegant as pushState
2009/10/18 Nelson Menezes flying.mushr...@gmail.com:
[1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
[2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html
Oops, sorry, I meant to give a couple of examples (above) of existing
approaches to maintain user UI state. [1]
On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com wrote:
Some comments:
I think an optimization that enables the server to strip unnecessary content
is a MUST.
Well, as I explained, it's not really a MUST. Doing an ordinary
navigation requests an entire page, and without
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com wrote:
It seems the browser will need to make a distinction between a regular
request and a request invoked by a bookmark.
In case of a bookmark the server should not strip
On Sun, Oct 18, 2009 at 10:07 AM, Nelson Menezes
flying.mushr...@gmail.com wrote:
I guess the base @onlyreplace would probably be an important part of
making this truly useful. There might be too many maintainability
problems stemming from having @onlyreplace all over the place on links
Nelson Menezes wrote:
2009/10/18 Ian Hickson i...@hixie.ch:
On Sat, 17 Oct 2009, Schuyler Duveen wrote:
One of the big issues we found using it on some other sites is that
javascript listeners (rather than onclick= attributes), and other DOM
pointers in the system became stale. Thus, only
bay117-w90f5b859cd291ac4e373b83...@phx.gbl
dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
When I said an optimization is a must I didn't just mean bandwidth.
Imagine this use
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
Nelson Menezes wrote:
2009/10/18 Ian Hickson i...@hixie.ch:
On Sat, 17 Oct 2009, Schuyler Duveen wrote:
One of the big issues we found using it on some other sites is that
javascript listeners (rather than
On Sun, Oct 18, 2009 at 11:22 AM, tali garsiel t_gars...@hotmail.com wrote:
When I said an optimization is a must I didn't just mean bandwidth.
Imagine this use case:
You have a page with a chart and a table showing data calculated from complex
statistical analysis on your huge database.
On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Well, the point is that this should generally act as just an
optimization of normal navigation. Clicking on a href=foo
onlyreplace=bar should give you the same result as clicking on a
href=foo, just without the
2009/10/18 Scott González scott.gonza...@gmail.com:
On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Well, the point is that this should generally act as just an
optimization of normal navigation. Clicking on a href=foo
onlyreplace=bar should give you the same
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
Nelson Menezes wrote:
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event. Maybe something like:
document.addEventListener('replaceonly')
with the event
On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
Nelson Menezes wrote:
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event.
dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com
bay117-w9daba5e3a74376fb4bbfc83...@phx.gbl
dd0fbad0910180935i6b07e025t14f4cc5aaacb3...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
I'll try to fix
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
As long as the event bubbles, you can always just listen at the
document root and then check event.target to see who got updated.
That way you don't have to wait, nor do you have to know which
specific bits are getting replaced.
You would want
On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
As long as the event bubbles, you can always just listen at the
document root and then check event.target to see who got updated.
That way you don't have to wait,
On Sat, Oct 17, 2009 at 1:22 AM, Jonas Sicking jo...@sicking.cc wrote:
Also, what should happen if the user presses the 'back' button?
It should be the same as for regular navigation. If the UA usually
stores some page state in a cache when the user navigates, it should
store the same state.
On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Okay, so possible revision: base onlyreplace=foo carries a list of
ids to replace. This automatically makes all links and forms on the
On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I think the opposite. If I upgraded my site to this, I'd want nearly
all the links to onlyreplace. There's only a handful of same-origin
links that I'd instead want to trigger a full load.
It's very common for
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
As long as the event bubbles, you can always just listen at the
document root and then check event.target to see
On Sun, Oct 18, 2009 at 2:31 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
Sorry, I had in mind being able to re-apply event listeners to the DOM
once the new content was loaded. Of course you can do that in several
localised places rather than overall on the whole document (it will be
On Sun, Oct 18, 2009 at 1:15 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I think the opposite. If I upgraded my site to this, I'd want nearly
all the links to onlyreplace. There's only a handful of same-origin
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
The problem is that people will make links that refresh different parts
of a document, to the point that the current document is no longer
addressable. Use cases for this happen often enough
On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen wha...@graffitiweb.org wrote:
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
The problem is that people will make links that refresh different parts
of a document, to the point that the
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen wha...@graffitiweb.org
wrote:
Tab Atkins Jr. wrote:
On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
The problem is that people will make links that refresh different parts
of a document,
On Fri, Oct 16, 2009 at 4:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
[snip]
Isn't if inefficient to request the whole page and then throw most of
it out? With proper AJAX you can just request the bits you want.
==
This is a valid
2009/10/17 Jonas Sicking jo...@sicking.cc:
On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Promoting this reply to top-level because I think it's crazy good.
On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Fri, Oct 16, 2009 at
On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Promoting this reply to top-level because I think it's crazy good.
On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor simetrical+...@gmail.com
Tab Atkins Jr. schrieb:
On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking jo...@sicking.cc wrote:
Also, what should happen if the user presses the 'back' button?
If the browser can remember what the page state was previously, just
swap in the old parts. If not, but it at least remembers what
This feels like really nice sugar, but maybe the first step should be to get
the shim out that gets it working using JS now and then see how it works
in practice. I totally understand why this looks exciting, but I have the
same uneasiness as Jonas. It feels like a LOT of magic to go grab a
On Sat, Oct 17, 2009 at 11:16 AM, Dion Almaer d...@almaer.com wrote:
This feels like really nice sugar, but maybe the first step should be to get
the shim out that gets it working using JS now and then see how it works
in practice. I totally understand why this looks exciting, but I have
2009/10/17 Jonas Sicking jo...@sicking.cc:
In fact, you don't even need to use pushState. For now this can be
faked using onhashchange and fragment identifier tricks. It's
certainly not as elegant as pushState (that is, after all, why
pushState was added), but it's something that can be tried
).
cheers,
sky
Date: Sat, 17 Oct 2009 11:34:25 -0700
From: Jonas Sicking jo...@sicking.cc
To: Dion Almaer d...@almaer.com
Cc: Markus Ernst derer...@gmx.ch, Tab Atkins Jr.
jackalm...@gmail.com, Aryeh Gregor simetrical+...@gmail.com,
whatwg wha...@whatwg.org
Subject: Re: [whatwg
Promoting this reply to top-level because I think it's crazy good.
On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
As well, this still doesn't answer the question of what to do with
A few public responses to issues/questions brought up in IRC: (thanks,
Aryeh and Philip!)
How is this better than iframe seamless and a target?
=
It's significantly better in multiple ways, actually.
1. iframes, like frames before them,
Tab Atkins Jr. schrieb:
Promoting this reply to top-level because I think it's crazy good.
[...]
Let's say we add a new attribute to a, like a onlyreplace=foo,
where foo is the id of an element on the page. Or better, a
space-separated list of elements. When the user clicks such a link,
the
On Fri, Oct 16, 2009 at 4:10 PM, Markus Ernst derer...@gmx.ch wrote:
Yes it looks like an AJAX killer.
Well, for a particular common, useful pattern. AJAX will still be
alive and well for solving more general classes of problems.
Actually the problem I mentioned for Aryehs first proposal
Tab Atkins Jr. schrieb:
[...]
The body of page1.html could look like:
div id=pageHeaderRecipies for vegetarians/div
div id=content
h1Lovely broccoli/h1
pTake the broccoli and do the following:/p
...
/div
ul id=navigation
lispanBroccoli/span/li
lia href=page2.html
On Fri, Oct 16, 2009 at 5:08 PM, Markus Ernst derer...@gmx.ch wrote:
(Also, in your examples you probably want @onlyreplace=content
navigation, since your nav is changing from page to page as well.
Indeed. Or, maybe I'd do it slightly differently, somehow like:
ul id=navigation
lia
On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Promoting this reply to top-level because I think it's crazy good.
On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr. jackalm...@gmail.com
62 matches
Mail list logo
