Re: [whatwg] hashchange only dispatched in history traversal
I think Ian has misunderstood, so I dare repeat: For bookmark navigation (scrolling), generate a reveal event. For AJAX hacking (no scrolling), generate a hash update event. This means the page has changed semantically. In particular, I never said the hash update event should be dropped. The only way I can understand the relevance of Ian's text is that he thinks the reveal event would not be useful. I think it can be an advantage to special designs with floating windows and such. HTH, Chris
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, 18 Feb 2009, Kristof Zelechovski wrote: I think Ian has misunderstood, so I dare repeat: For bookmark navigation (scrolling), generate a reveal event. For AJAX hacking (no scrolling), generate a hash update event. This means the page has changed semantically. In particular, I never said the hash update event should be dropped. The only way I can understand the relevance of Ian's text is that he thinks the reveal event would not be useful. I think it can be an advantage to special designs with floating windows and such. I do not understand your proposal. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, 10 Sep 2008, Kristof Zelechovski wrote: I think the main problem here is that we want to package two different functions into one event. The legitimate use of hash change where it is used to reveal a bookmark should trigger an event named reveal dispatched to the target anchor and bubbling, where the handler for the Window object can be specified as BODY[onreveal]. The AJAX abuse where it is used to change the context of the page, whereas it can be determined when no corresponding target anchor can be found, should trigger the hash change notification broadcast to every object of the active document that registers for it by declaring a handler. Does this make sense? It seems that using onload= for the initial setup and onhashchange= for subsequent updates would most closely match the likely architecture of Web applications. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Tue, Sep 9, 2008 at 1:49 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 9 Sep 2008, Garrett Smith wrote: Please be patient. There are literally thousands of e-mails that will need to be dealt with before yours. I am being patient. There may very well be a list subscriber who has the answer. It's an open question to a public list. Garrett -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
I think the main problem here is that we want to package two different functions into one event. The legitimate use of hash change where it is used to reveal a bookmark should trigger an event named reveal dispatched to the target anchor and bubbling, where the handler for the Window object can be specified as BODY[onreveal]. The AJAX abuse where it is used to change the context of the page, whereas it can be determined when no corresponding target anchor can be found, should trigger the hash change notification broadcast to every object of the active document that registers for it by declaring a handler. Does this make sense? Chris
Re: [whatwg] hashchange only dispatched in history traversal
On Tue, Sep 9, 2008 at 12:48 PM, Garrett Smith [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2008, Garrett Smith wrote: and what if you have: body onhashchange=alert(document.body.ohashchange); ^ Should be onhashchange, alert(document.body.onhashchange); Garrett -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hashchange only dispatched in history traversal
On Tue, Sep 9, 2008 at 12:48 PM, Garrett Smith [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2008, Garrett Smith wrote: and what if you have: body onhashchange=alert(document.body.ohashchange); ^ Should be onhashchange, alert(document.body.onhashchange); Garrett -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hashchange only dispatched in history traversal
On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 21 Aug 2008, Garrett Smith wrote:
HTML 5 expands hashchange to any element. Any element, such as div
or pre? How can you know if an element supports hashchange or not?
I still wonder about this.
hashchange seems closely related to the Location interface, so it
would seem to make sense to have hashchange implemented for objects
that implement Location.
Has this been considered?
Yes, but the benefit of being able to do body onhashchange= outweighs
the logicalness of dispatching events to the Location object.
I still wonder what the benefit is.
I'm not sure what that has to do with the body element.
Nothing especially, except that that is where the event is fired, so
that you can do body onhashchange=
and what if you have:
body onhashchange=alert(document.body.ohashchange);
Expected result: ?
Should this elert undefined?
What is the handler's scope? What is the context?
I see:
| The function's this parameter must be the Element object
representing the element.
http://www.w3.org/html/wg/html5/#event5
But that isn't what happens when a DOM 0 Event clobbers the body tag.
minor-editorial-nitpick
The wording should be changed to: The function's context or The
function's thisArg.
/minor-editorial-nitpick
fires at the body element sounds as if the event is firing itself,
at the body. Instead, say the EventTarget fires the event. For example:
The window fires the hashchange event.
I disagree with your interpretation of the terminology, but that's not
just editorial so it's not a big deal.
I believe the problem may be more than editorial.
Body event handler attributes cascading to window is unclear and creates
ambiguity as to what the event is being attached to.
body onmousedown=alert(this)
alerts window in Firefox 3. The mousedown event fires anywhere, not
just on the body. This creates ambiguity. So it is a practice that
should be avoided in attempt to be cross browser. Has this problem been
considered?
Yeah, this is an open issue. I'm hoping that the DOM Events spec handles
it.
Handles what?
A BODY event handler can be added as a content attribute to the BODY
tag. It should generally have the scope chain as
body-document-window, with the context as body (this === body);
The following example shows that this is true:-
!DOCTYPE HTML
html
headtitleonclick content handler test/title/head
script type=text/javascriptvar title=1/script
style type=text/css*{white-space: pre;font-family:monospace}/style
body title=body
onclick=document.body.innerHTML+=
'\ncurrentTarget is body: '+(event.currentTarget === document.body)
+ '\ncontext is body: ' + (this === document.body)
+ '\nscope is window: ' + (title === 'body');
p(click) All should be true:/p/body
/html
Result:
currentTarget is body: true
context is body: true
scope is window: true
Except in Firefox. In Firefox, the scope and context are window:
currentTarget is body: false
context is body: false
scope is window: false
We can also observe that clicking anywhere in the window will trigger
the event. Firefox handles click events for window and the equivalent
event handler content attribute is assigned in the BODY tag.
This may seem strange, but it is the way that DOM 0 events for window
work. Window has no tag. Content handler attributes for window are
place in the BODY tag. This is true for all DOM 0 events, such as
onload, onunload, onfocus, onblur.
For example, onload:-
!DOCTYPE HTML
html
headtitleonload content handler test/title/head
script type=text/javascriptvar title=1/script
style type=text/css*{white-space: pre;font-family:monospace}/style
body title=body
onload=var target = event.target || event.srcElement;
document.body.innerHTML+='\ntarget is document: '+(target === document)
+ '\ncontext is window: ' + (this === window)
+ '\nscope is window: ' + (title === 1);
pAll should be true:/p/body
/html
We can already observe some ambiguity. It may seem odd to some that
Firefox has mouseevents for window, but it does. Firefox has also has
keyEvent,s mousewheel events. What happens when the event is focus?
Any element with tabIndex can now have focus, and window can have a
different kind of focus. What happens when BODY has an onfocus content
handler? What happens when BODY has an event handler content attribute
with the same name as a window event?
This example shows that we can add an onfocus content handler to a p
tag, and an onfocus content handler to the body, but that the window's
onfocus wins the event handler assignment in Firefox, Opera, and
Safari.
!DOCTYPE HTML
html
headtitleonfocus content handler test/title/head
script type=text/javascriptvar title=1/script
style type=text/css*{white-space: pre;font-family:monospace}/style
body title=body tabindex=1 style=position:absolute
onfocus=document.body.innerHTML+=
'\ncontext is window: ' + (this === window)
+ '\nscope is window: ' + (title
Re: [whatwg] hashchange only dispatched in history traversal
On Tue, 9 Sep 2008, Garrett Smith wrote: HTML 5 expands hashchange to any element. Any element, such as div or pre? How can you know if an element supports hashchange or not? I still wonder about this. Yes, but the benefit of being able to do body onhashchange= outweighs the logicalness of dispatching events to the Location object. I still wonder what the benefit is. You feedback has been filed already and will be considered in due course: http://www.whatwg.org/issues/#dom-events Please be patient. There are literally thousands of e-mails that will need to be dealt with before yours. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, 20 Aug 2008, Garrett Smith wrote: http://www.whatwg.org/specs/web-apps/current-work/#onhashchange | onhashchange | |Must be invoked whenever a hashchange event | is targeted at or bubbles through the element. I see it fires on History Traversal: | If the specified entry has a URL that differs from the current entry's | only by its fragment identifier, and the two share the same Document | object, then fire a simple event with the name hashchange at the body | element Is 'hashchange' an event that fires every time window.location.hash changes? Yes. I'm not sure what that has to do with the body element. Nothing especially, except that that is where the event is fired, so that you can do body onhashchange= This may be one of those new ideas that may not ever see widespread implementation. It's already implemented in IE8. I'm interested in discussing the other issue that is more relevant to existing standards and implementations (Misconceptions Documented). I will reply to all feedback in due course; the IDL-related issues are currently awaiting WebIDL updates that that the HTML5 spec can be updated. You can see what e-mails are still pending replies here: http://whatwg.org/issues/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, Aug 20, 2008 at 11:00 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 20 Aug 2008, Garrett Smith wrote:
http://www.whatwg.org/specs/web-apps/current-work/#onhashchange
| onhashchange
|
|Must be invoked whenever a hashchange event
| is targeted at or bubbles through the element.
I see it fires on History Traversal:
| If the specified entry has a URL that differs from the current entry's
| only by its fragment identifier, and the two share the same Document
| object, then fire a simple event with the name hashchange at the body
| element
Is 'hashchange' an event that fires every time window.location.hash
changes?
Yes.
I see that in MSDN now that hashchange applies to (window, BODY, FRAMESET).
HTML 5 expands hashchange to any element. Any element, such as div
or pre? How can you know if an element supports hashchange or not?
hashchange seems closely related to the Location interface, so it
would seem to make sense to have hashchange implemented for objects
that implement Location.
Has this been considered?
This would make it easier to know which elements support hashchange
events (body doesn't really support the event, it's just a pass-thru).
It would make the most sense to have hashchange *on* the Location, e.g.
location.addEventListener('hashchange', cb, false);
- but that would not be compatible with IE.
I'm not sure what that has to do with the body element.
Nothing especially, except that that is where the event is fired, so that
you can do body onhashchange=
fires at the body element sounds as if the event is firing itself,
at the body. Instead, say the EventTarget fires the event. For
example: The window fires the hashchange event.
Body event handler attributes cascading to window is unclear and
creates ambiguity as to what the event is being attached to.
body onmousedown=alert(this)
alerts window in Firefox 3. The mousedown event fires anywhere, not
just on the body. This creates ambiguity. So it is a practice that
should be avoided in attempt to be cross browser. Has this problem
been considered?
1) add a note about bubbling. hashchange events bubble
2) replace the fires at the body element with the EventTarget fires
the event
Garrett
--
Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hashchange only dispatched in history traversal
On Thu, 21 Aug 2008, Garrett Smith wrote: HTML 5 expands hashchange to any element. Any element, such as div or pre? How can you know if an element supports hashchange or not? I'm not sure what you mean. In HTML5, all event handler _attributes_ can be placed on any element, but that doesn't mean that the event will be fired by the UA at any element. The spec only fires the event at the body element. hashchange seems closely related to the Location interface, so it would seem to make sense to have hashchange implemented for objects that implement Location. Has this been considered? Yes, but the benefit of being able to do body onhashchange= outweighs the logicalness of dispatching events to the Location object. I'm not sure what that has to do with the body element. Nothing especially, except that that is where the event is fired, so that you can do body onhashchange= fires at the body element sounds as if the event is firing itself, at the body. Instead, say the EventTarget fires the event. For example: The window fires the hashchange event. I disagree with your interpretation of the terminology, but that's not just editorial so it's not a big deal. Body event handler attributes cascading to window is unclear and creates ambiguity as to what the event is being attached to. body onmousedown=alert(this) alerts window in Firefox 3. The mousedown event fires anywhere, not just on the body. This creates ambiguity. So it is a practice that should be avoided in attempt to be cross browser. Has this problem been considered? Yeah, this is an open issue. I'm hoping that the DOM Events spec handles it. 1) add a note about bubbling. hashchange events bubble Per the spec, it doesnt. 2) replace the fires at the body element with the EventTarget fires the event I disagree with this interpretation of the terminology. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Thu, Aug 21, 2008 at 4:09 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 21 Aug 2008, Garrett Smith wrote:
HTML 5 expands hashchange to any element. Any element, such as div
or pre? How can you know if an element supports hashchange or not?
I'm not sure what you mean. In HTML5, all event handler _attributes_ can
be placed on any element, but that doesn't mean that the event will be
fired by the UA at any element. The spec only fires the event at the body
element.
The spec fires an event at the body element? LOL What does that mean?
Can you explian this using standard terms like currentTarget and
thisArg?
That's funny.
Detecting support for events is painful. Detecting hashchange events,
given the current design, will be very painful.
hashchange seems closely related to the Location interface, so it
would seem to make sense to have hashchange implemented for objects
that implement Location.
Has this been considered?
Yes, but the benefit of being able to do body onhashchange= outweighs
What benefit?
the logicalness of dispatching events to the Location object.
The design association of Location --- LocationEvents
would seem to make browser scripting very easy. Once a location object
is obtained, it can be assumed to behave the way all location objects
behave. That would mean that it might be a fair inference to test:
if(location.addEventListener),
but that might be too loose an inference. A more thorough approach would be:-
var EventSupport = {};
if(location.addEventListener) {
(function(){
var es = EventSupport;
// Initialize the touch and gesture properties.
es.location = hasSupport(LocationEvent);
function hasSupport(s){
try {
document.createEvent(s);
return true;
} catch (e) {
return false;
}
}
})();
}
I'm not sure what that has to do with the body element.
Nothing especially, except that that is where the event is fired, so
that you can do body onhashchange=
That precludes the ability that hashchange would ever be supported on
body element. What's worse, the body element is far removed from the
event. It's not clear what the event target is or what the
event.target should be when the event fires. It is unclear what the
thisArg will be. The body is a child of the documentElement, which is
a child of the document, which is a property of the window. It's far
removed.
Body's event handlers propagating to window worked in legacy browsers.
These browsers had such bararic APIs that design didn't matter. Demand
changed, browsers changed. Modern browsers are rich enough to
accommodate rich browser side applications and the trend forwards is
towards richer and richer functionality. API design matters more.
Body event handler attributes cascading to window is unclear and creates
ambiguity as to what the event is being attached to.
body onmousedown=alert(this)
alerts window in Firefox 3. The mousedown event fires anywhere, not
just on the body. This creates ambiguity. So it is a practice that
should be avoided in attempt to be cross browser. Has this problem been
considered?
Yeah, this is an open issue. I'm hoping that the DOM Events spec handles
it.
Hoping? Why?
Creating ambiguous, illogical, confusing programming constructs is bad.
Such features will get used and the ambiguity will be realized in
implementations and with less careful, less knowledgeable developers
who did not memorize the complexities of an ambiguous API.
Such practices can be deprecated and discouraged in favor of features
that work better. This can be effective and font is good evidence.
Not much new code uses font because we have CSS working. This type
of new bad feature seems to be something that should be considered.
Hindsight is always better and retrospectively, we can see things that
the earlier specs got wrong. Using tests to write out proposals would
be a way to avoid this. For example, for hashchange feature, a test
could be wrote. it would fail, but we would see the design of the API.
From there, we could hack up a poll function using setInterval, and
with that, we could see the effect of how the API would work. It's
more work, but would seem to be worthwhile insurance.
1) add a note about bubbling. hashchange events bubble
Per the spec, it doesnt.
Ah, but per MSDN, it does.
http://msdn.microsoft.com/en-us/library/cc288209(VS.85).aspx
Specifying this in a different manner than the way it is specified in
MSDN is a good way to make browser scripting more difficult.
IE's hashchange bubbles.
Was this considered?
2) replace the fires at the body element with the EventTarget fires
the event
I disagree with this interpretation of the terminology.
Then can you write something using standard terminology? I really
don't know what fires at the [xxx] means.
Thanks.
Garrett
--
Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hashchange only dispatched in history traversal
I am very disappointed. onhashchange intuitively means that the content hash changes (which is more or less equivalent to modifying the content, of course). I would call this event onreveal to be in line with the primary bookmark semantics. The name is inspired by the Finder AppleScript dictionary, of course. Please reconsider. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, August 20, 2008 3:14 AM To: Leons Petrazickis; Agustín Cc: Michael A. Puls II; WHATWG; Maciej Stachowiak Subject: Re: [whatwg] hashchange only dispatched in history traversal On Wed, 15 Aug 2007, Leons Petrazickis wrote: On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote: On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. I've always referred to fragment indentifiers as in-page anchors. So, why not: body onanchorchange= I think it's more readable than onfragmentidentifierchange We ended up using onhashchange=.
Re: [whatwg] hashchange only dispatched in history traversal
2008/8/20 Křištof Želechovski : I am very disappointed. onhashchange intuitively means that the content hash changes (which is more or less equivalent to modifying the content, of course). onlocationhashchange? ...because it's fired when location.hash changes... (I have personally no problem with onhashchange)
Re: [whatwg] hashchange only dispatched in history traversal
On Tue, Aug 19, 2008 at 6:13 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 15 Aug 2007, Leons Petrazickis wrote: On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote: On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: We ended up using onhashchange=. What is this? Garrett On Wed, 15 Aug 2007, Agustín wrote: [snip] -- Ian Hickson U+1047E
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, 15 Aug 2007, Leons Petrazickis wrote: On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote: On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. I've always referred to fragment indentifiers as in-page anchors. So, why not: body onanchorchange= I think it's more readable than onfragmentidentifierchange We ended up using onhashchange=. On Wed, 15 Aug 2007, Agust�n wrote: There are interesting cases to think of: what happens with anchors which are not handled by the application? The browser won't know that and will probably store the 404 not found error equivalent page in the location bar autocomplete history. How could this be handled? This problem doesn't exist just for anchorchange events, since the non-existing location might be the first url the user visits and then there would be no opportunity to notify the browser that the url is invalid. Perhaps this could be handled by adding some method in the history object. Anyway, I guess that we can live without this. We can get around this using location.replace() and some JS. That's how http://whatwg.org/html5 handles redirects when you give fragment identifiers from other pages in the multipge doc, for example. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. addEventListener(fragmentidentifierchange doesn't seem too bad to me. And, if for some reason you wanted it shortened in your script, you could just do: var hashchange = fragmentidentifierchange; a.addEventListener(hashchange b.addEventListener(hashchange c.addEventListener(hashchange I don't know. body onfragmentidentifierchange= ...seems a bit overly long to me, still. True. As an attribute with the on part, it looks pretty bad. -- Michael
Re: [whatwg] hashchange only dispatched in history traversal
On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote: On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. addEventListener(fragmentidentifierchange doesn't seem too bad to me. And, if for some reason you wanted it shortened in your script, you could just do: var hashchange = fragmentidentifierchange; a.addEventListener(hashchange b.addEventListener(hashchange c.addEventListener(hashchange I don't know. body onfragmentidentifierchange= ...seems a bit overly long to me, still. True. As an attribute with the on part, it looks pretty bad. I've always referred to fragment indentifiers as in-page anchors. So, why not: body onanchorchange= I think it's more readable than onfragmentidentifierchange There is an HTMLCollection anchors that only lists a name= elements. Extending the link-anchor metaphor into Javascript, the fragment identifier anchors a DOM state. When a fragment identifier changes, the anchor of the DOM state changes. Regards, Leons Petrazickis Database Technology Advocate, IBM http://lpetr.org/blog/
Re: [whatwg] hashchange only dispatched in history traversal
Hi, anchorchange I like anchorchange, I think it's the most descriptive of all the proposed names. Otherwise, hashchange is good enough for me. Can the event be preventDefaulted? - Also, could the default action of the event be prevented? I think that to have a working implementation we shouldn't require that. However: 404 not found for anchors - There are interesting cases to think of: what happens with anchors which are not handled by the application? The browser won't know that and will probably store the 404 not found error equivalent page in the location bar autocomplete history. How could this be handled? This problem doesn't exist just for anchorchange events, since the non-existing location might be the first url the user visits and then there would be no opportunity to notify the browser that the url is invalid. Perhaps this could be handled by adding some method in the history object. Anyway, I guess that we can live without this. . A . On Wed, 2007-08-15 at 08:30 -0400, Leons Petrazickis wrote: There is an HTMLCollection anchors that only lists a name= elements. Extending the link-anchor metaphor into Javascript, the fragment identifier anchors a DOM state. When a fragment identifier changes, the anchor of the DOM state changes.
Re: [whatwg] hashchange only dispatched in history traversal
A fragment identifier was rather like a bookmark because you cannot have a big fragment inside an anchor because a big fragment is a block-level element and an anchor would not like having a block-level element inside. On the other hand, the path of the URL refers to the whole document, not just to the beginning of the document. That is the difference between a fragment and a bookmark. A fragment has the beginning and the end; a bookmark does not have the end or, if you prefer, it is like an empty fragment where the end is equal to the beginning (it is in the same block-level element). Chris -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Sunday, August 12, 2007 11:59 PM To: Krzysztof Żelechowski Cc: 'Ian Hickson'; 'WHATWG' Subject: Re: [whatwg] hashchange only dispatched in history traversal On Aug 12, 2007, at 10:38 AM, Krzysztof Żelechowski wrote: Dnia sobota, 11 sierpnia 2007 22:14, Maciej Stachowiak napisał: On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. In the early '90s? And I did not say it was called a bookmark but it was like a bookmark semantically. Apparently it's been called a fragment identifier for about as long as the World Wide Web has existed. I don't know what you mean by like a bookmark semantically. It's no more or less like a bookmark than any other part of a URI. Regards, Maciej
Re: [whatwg] hashchange only dispatched in history traversal
Dnia sobota, 11 sierpnia 2007 22:14, Maciej Stachowiak napisał: On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. In the early '90s? And I did not say it was called a bookmark but it was like a bookmark semantically. Chris
Re: [whatwg] hashchange only dispatched in history traversal
On Aug 12, 2007, at 10:38 AM, Krzysztof Żelechowski wrote: Dnia sobota, 11 sierpnia 2007 22:14, Maciej Stachowiak napisał: On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. In the early '90s? And I did not say it was called a bookmark but it was like a bookmark semantically. Apparently it's been called a fragment identifier for about as long as the World Wide Web has existed. I don't know what you mean by like a bookmark semantically. It's no more or less like a bookmark than any other part of a URI. Regards, Maciej
Re: [whatwg] hashchange only dispatched in history traversal
Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. Best regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Saturday, August 11, 2007 12:15 AM To: Maciej Stachowiak Cc: WHATWG Subject: Re: [whatwg] hashchange only dispatched in history traversal I kind of like onfragmentload but fragment seems to have connotations of bits of documents rather than of fragment identifiers. I don't think it's necessarily any clearer than hash... I don't know.
Re: [whatwg] hashchange only dispatched in history traversal
How about onreveal? Motivation: AppleScript Finder suite has event miscmvis (make visible) that the Finder dictionary shortens to reveal as in Tell application Finder to reveal controls panels folder That more or less corresponds to the URL file:///Startup%20Disk/System%20Folder/#Control%20Panels Just a brainstorm idea. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Saturday, August 11, 2007 12:11 AM To: Ian Hickson Cc: WHATWG Subject: Re: [whatwg] hashchange only dispatched in history traversal On Aug 10, 2007, at 12:35 PM, Ian Hickson wrote: But, I'm very open to changing the event name. What would you suggest? Some suggestions: onfragmentscroll (thought it might not scroll if nothing has that fragment ID) onfragmentchanged onfragmentload (not quite accurate but reminiscent of onload) Regards, Maciej
Re: [whatwg] hashchange only dispatched in history traversal
On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. Best regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Saturday, August 11, 2007 12:15 AM To: Maciej Stachowiak Cc: WHATWG Subject: Re: [whatwg] hashchange only dispatched in history traversal I kind of like onfragmentload but fragment seems to have connotations of bits of documents rather than of fragment identifiers. I don't think it's necessarily any clearer than hash... I don't know.
Re: [whatwg] hashchange only dispatched in history traversal
Fragment identifier seems to go back to at least 1994: http://www.ietf.org/rfc/rfc1630.txt Linus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Saturday, August 11, 2007 1:14 PM To: Křištof Želechovski Cc: 'WHATWG'; 'Ian Hickson' Subject: Re: [whatwg] hashchange only dispatched in history traversal On Aug 11, 2007, at 10:00 AM, Křištof Želechovski wrote: Originally the name after the hash was a bookmark, not a fragment, because it would be defined on an anchor. I agree that until the new semantic makes it to the common knowledge using the name fragment for the purpose may be surprising for some developers. When was it called a bookmark? I'm pretty sure it has been called a fragment identifier back to at least the late '90s. Best regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Saturday, August 11, 2007 12:15 AM To: Maciej Stachowiak Cc: WHATWG Subject: Re: [whatwg] hashchange only dispatched in history traversal I kind of like onfragmentload but fragment seems to have connotations of bits of documents rather than of fragment identifiers. I don't think it's necessarily any clearer than hash... I don't know.
Re: [whatwg] hashchange only dispatched in history traversal
On 8/10/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: I would also suggest calling it something other than hashchange. I realize the term hash is used in other places in the HTML DOM to refer to the fragment ID but it sounds weird in an event name like that. CSS uses target and the URI RFC uses fragment identifier. I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. addEventListener(fragmentidentifierchange doesn't seem too bad to me. And, if for some reason you wanted it shortened in your script, you could just do: var hashchange = fragmentidentifierchange; a.addEventListener(hashchange b.addEventListener(hashchange c.addEventListener(hashchange -- Michael
Re: [whatwg] hashchange only dispatched in history traversal
On Aug 10, 2007, at 2:20 AM, Anne van Kesteren wrote: Wouldn't it make sense to dispatch the event whenever location.hash changes value? When following a link for instance? (Unless I misunderstood something it's currently only dispatched in history traversal.) I agree with Anne's suggestion. I would also suggest calling it something other than hashchange. I realize the term hash is used in other places in the HTML DOM to refer to the fragment ID but it sounds weird in an event name like that. CSS uses target and the URI RFC uses fragment identifier. Regards, Maciej
Re: [whatwg] hashchange only dispatched in history traversal
On Fri, 10 Aug 2007, Anne van Kesteren wrote: Wouldn't it make sense to dispatch the event whenever location.hash changes value? When following a link for instance? (Unless I misunderstood something it's currently only dispatched in history traversal.) History traversal happens as part of navigation. On Fri, 10 Aug 2007, Maciej Stachowiak wrote: I would also suggest calling it something other than hashchange. I realize the term hash is used in other places in the HTML DOM to refer to the fragment ID but it sounds weird in an event name like that. CSS uses target and the URI RFC uses fragment identifier. target is far too overloaded in HTML and DOM to use here, IMHO (it means both DOM Event target and browsing context target during navigation -- both of which are actually relatively close to what we're talking about). fragment identifier is what I originally was going to use as part of the event name. But the event name would be _long_: onfragmentidentifierchanged= ...and shortening it: onfragidchanged= ...leads to something that isn't IMHO that much clearer or better than what we have now: onhashchanged= The advantage of hashchanged is that it is very literal -- the attribute called hash changed just before the event fired. But, I'm very open to changing the event name. What would you suggest? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Aug 10, 2007, at 12:35 PM, Ian Hickson wrote: ...leads to something that isn't IMHO that much clearer or better than what we have now: onhashchanged= The advantage of hashchanged is that it is very literal -- the attribute called hash changed just before the event fired. It's not firing on the location object, though, and A elements also have a hash attribute. So the relationship is a little indirect. But, I'm very open to changing the event name. What would you suggest? Some suggestions: onfragmentscroll (thought it might not scroll if nothing has that fragment ID) onfragmentchanged onfragmentload (not quite accurate but reminiscent of onload) Regards, Maciej
Re: [whatwg] hashchange only dispatched in history traversal
On Fri, 10 Aug 2007, Maciej Stachowiak wrote: Some suggestions: onfragmentscroll (thought it might not scroll if nothing has that fragment ID) onfragmentchanged onfragmentload (not quite accurate but reminiscent of onload) I kind of like onfragmentload but fragment seems to have connotations of bits of documents rather than of fragment identifiers. I don't think it's necessarily any clearer than hash... I don't know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
