Re: [whatwg] WA1: Conformance requirements
On 3/7/06, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 6 Mar 2006, L. David Baron wrote: [snip] The opening sentence: As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. is unnecessarily complicated. Instead, I would suggest combining it and the following sentence: All of this specification is normative, except for sections marked as non-normative, diagrams, examples, and notes. This was changed as a result of: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-December/002780.html I'm not convinced that your suggested improvement scans better, and it may in fact reintroduce the problem in a different way (does it refer to sections marked as diagrams?). How about this? All diagrams, examples and notes in this specification are non-normative, as are all sections explicitly marked non-normative. It's longer, but it doesn't leave any room for confusion that I can see, and it avoids starting with As well as. Aankhen -- Why don't you go on a diet! Because I like to eat! Is that a crime?
Re: [whatwg] Targetting different anchors after submitting the form
Ian Hickson wrote: On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form indeed: 2.17. Extensions to the submit buttons ... In some cases, authors would like to be able to submit a form to different processors, using different submission methods, or not replacing the form but just updating the details with new data. For this reason, the following attributes may be used on submit buttons: action, method, enctype, replace, and target. ... if only i could figure our how to compile the firefox source (i've tried on three seperate occasions it's just far too complicated with all the extra garbage you have to install and configure first!) i could see this as something i could put in a local version to assist with making test-cases of the spec. ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
Ric Hardacre wrote: Ian Hickson wrote: On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form indeed: 2.17. Extensions to the submit buttons ... In some cases, authors would like to be able to submit a form to different processors, using different submission methods, or not replacing the form but just updating the details with new data. For this reason, the following attributes may be used on submit buttons: action, method, enctype, replace, and target. ... I did check the spec but somehow I missed that. Thanks for pointing it out. I just hit the problem yesterday and I was wondering which kind of support for this kind of feature I should be expecting in the future, so I can make our internal application framework to be ready for it. -- Mikko
Re: [whatwg] Targetting different anchors after submitting the form
Quoting Ric Hardacre [EMAIL PROTECTED]: if only i could figure our how to compile the firefox source (i've tried on three seperate occasions it's just far too complicated with all the extra garbage you have to install and configure first!) i could see this as something i could put in a local version to assist with making test-cases of the spec. Feel free to download a weekly build of Opera 9.0: http://my.opera.com/desktopteam/ ... and test how it works. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] [html5] createPattern() with image being of the wrong type
http://whatwg.org/specs/web-apps/current-work/#createpatternimage does not specify what should happen when the image argument is of the wrong type. The specification should probably say that in that case the TYPE_MISMATCH_ERR exception should be thrown just as it does for drawImage()... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] anchor(jump) DOM Event proposal
Ric Hardacre wrote: sounds good, and logical when compared with anchor and button onclick for example. to clarify, where would the event be attached by default? document or window? i.e. would i I'd say it would be attached to the same places as the load event. I've had a look at the Session history and navigation state spec and if I'm interpreting it correctly, it only solves part of the problem. Using state objects you would: 1) Implement the popstate event 2) use the window.pushState(stateobject) to push the state into the state stack? 3) When user navigates back, popstate event fires with the state object From the terminology, I gather that once you popped the state, you don't have the state in your history anymore? That means after you navigate back, you can't go forwards again. The state spec also leaves room for a URI to be associated with the state. But it begs the question of how will the URI be correlated to the state DOMObject in way that the URI can restore the state, even if the URI is posted to a web page, or sent via email to a friend. However, The good thing about the state spec is that it was created with the explicit intention of solving the AJAX problem, where as the onanchor spec is more of a piggy back on to an existing feature. Indeed, I came up with this spec when I set out to solve the AJAX problem with the current range of browsers, but fell short, because I couldn't find an event that would be reliably triggered when the anchor URL changes. I think the two specs, onanchor/state can be reconciled. The traditional anchor jumping could be made a behaviour of a modified state spec. Each jump will be regarded as a new state of page in the session history. It will however need some modifications for it to be able to perform like it is on current browsers (going forward, URL change, scrolling). cheers, -l
Re: [whatwg] diffed versions (CVS)
On Fri, 3 Mar 2006, Jim Ley wrote: On 3/3/06, Ian Hickson [EMAIL PROTECTED] wrote: http://svn.whatwg.org/ Excellent, thank you very much. My pleasure. Converting the spec to wiki format is not an option while I'm an editor. Good, Please don't do this even if some new editor came along - which I don't want either. Aww, shucks. SVN is great, a few more dated call for comments (which would be even harder with a wiki) would be nice too, but not essential. Yeah... I plan on doing a dated CFC when the spec reaches some sort of semi-stable point -- at the moment it's in pretty high flux, and areas are either needing thorough rewrites, or testing, or first drafts, before they are ready for any serious commentary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
