Re: [whatwg] HTML5 Parsing spec first draft ready
Quoting Ian Hickson [EMAIL PROTECTED]: The first draft of the HTML5 Parsing spec is ready. Great! It's not 100% complete. Some of the things that need work are: Interaction with document.open/write/close is undefined How to determine the character encoding Integration with quirks mode problems style parsing needs tweaking if we want to exactly match IE base parsing needs tweaking to handle multiple bases isindex needs some prose in the form submission section No-frames and no-script modes aren't yet defined Execution of script is not yet defined New HTML5 elements aren't yet defined There are various cases (marked) where EOF handling is undefined Interaction with the load event is undefined However, none of the above are particularly critical to the parsing. Attribute parsing is. And there are some special cases made for that here and there. It would be good if that was specified as well. And if all the browsers implement the same parsing model, then HTML interoperability on the Web will take a huge leap forward. T'would be save everyone a lot of time. Would be a good thing indeed. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] oninput event
Christian Schmidt wrote: Quote from the current working draft (10 January 2006) http://whatwg.org/specs/web-forms/current-work/#the-change: UAs may delay firing the input event if the data entry is rapid. Authors must not rely on this event firing once for each key press, mouse input, or similar. I'm not sure what the intention is here. I assume key press, mouse input, or similar refers to whenever the control's value attribute changes, i.e. not key presses on arrow keys etc. UAs may delay firing the event, but are they allowed skip it? If UAs are NOT allowed to skip events, what is the purpose of delaying them? And what exactly does delaying mean (e.g. what is the value of the control's value attribute when the event eventually occurs)? If UAs ARE allowed to skip events, I think it is a reasonable requirement that the last event per control in a series of inputs is not skipped, so that e.g. oninput=output.value=value will always make the output control be in sync shortly after the last key press (but not necessarily while the user is typing rapidly). yes that's exactly the use i can foresee, i have this problem in an app I'm working on currently, we can either use onChange or onKeyPress to activate the totalizing function for a series of quantity and length boxes. (e.g. 12 at 4 meters, 8 at 3 meters, the total being the total metreage). neither event is entirely satisfactory, onChange only happens when the text box looses focus (which is not the usual behavior in standard windows apps and has been brought up in client consultation ass odd) and onkeypress would be overkill IMO and would also yield intermediate invalid results. e.g. if an input is changed from 8 to 12 the initial 1 of 12 would cause the total to go out of whack. so a good implementation of onInput would occur after onKeyPress and before onChanged and would be sensitive to the user's computer's typematic delay. ric
Re: [whatwg] HTML5 Parsing spec first draft ready
Ian Hickson wrote: So... The first draft of the HTML5 Parsing spec is ready. [...] In section 8.2.1. Tokenisation, should the sentence Command and character tokens have data read Comment and character tokens have data?
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Shadow2531 wrote: O.K. Then, it should be getElementByClassName*s*() where you have have 1 or more classname arguments. If you pass more than 1 class name, both class names have to be present in the classname attribute for the element to match. This seems like a sensible change. Call it getElementsByClassNames() would make it obvious that if you supply multiple class names, you get only elements with all those names. And it would be a reasonably obvious reduction that if you just supply a single name, you would get all elements which had that one class name. So we've ended up with: elem.getElementsByClassNames(foo); and elem.getElementsByClassNames([foo, bar]); or elem.getElementsByClassNames(foo, bar); or both. Are there similar functions in the DOM at the moment which can take multiple arguments? Do you pass an array or multiple individual arguments, or can you do both? Gerv I was *messing* around with 2 different *examples*. 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html That one supports: getElementsByClassName(string); getElementsByClassName(array); If the string has spaces in it, it's considered that nothing will match and returns null. If it's an array, all must be present for an element to match. 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html Now this one supports the same 2 types, but the string handling is different. The string is space-separated. So, with this second example, you can do: document.getElementsByClassName(aaa); document.getElementsByClassName([bbb, ccc]); document.getElementsByClassName(bbb ccc); (The second 2 produce the same result. The 3rd one might just be cleaner in certain situations) I'm liking what options the second example provides. (not necessarily the code as I just threw it together and didn't think about exceptions, optimization and code size. Plus I just used a global function for the example.) Do you agree with the string being space-separated? It seems to make sense at least for html where a classname can't have spaces. -- Shadow2531
Re: [whatwg] HTML5 Parsing spec first draft ready
On Mon, 13 Feb 2006, Dan Brickley wrote: Any plans for a test suite? eg. pairs of input files and normalised output? (if that makes sense...). I'd strongly recommend people put off creating a test suite until the spec is in more than a first draft, but yes, on the long term this is something we should definitely do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Parsing spec first draft ready
On Tue, 14 Feb 2006, Alexey Feldgendler wrote: It's not 100% complete. Some of the things that need work are: Interaction with the load event is undefined What's that for? I think it shouldn't be defined in the parsing spec. Well, it's not strictly part of the parser section I guess. HTML5 is more than the parser section though. I'm just thinking about the whole thing and what parts interact with the parser. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Parsing spec first draft ready
On Tue, 14 Feb 2006, Anne van Kesteren wrote: However, none of the above are particularly critical to the parsing. Attribute parsing is. And there are some special cases made for that here and there. It would be good if that was specified as well. Oh, crap, forgot about those. I even put a note in the spec about it. Better add that to the list of things I need to look at. Thanks for the reminder. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
