Re: [whatwg] getElementsByClassName()
Shadow2531 wrote: 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. looks good to me, the only quirk of this would be that you cant choose class=foo bar specifically over class=foo with gebcn(foo bar) but if this is the stated behaviour then i guess that's ok. on a side note, it might also be worth stating that in this case gebcn(foo bar) should only return the class=foo bar element once, not twice (one instance for foo and one instance for bar). just for completeness ric
[whatwg] oninput event
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). Christian
Re: [whatwg] getElementsByClassName()
On 2/15/06, Ric Hardacre [EMAIL PROTECTED] wrote: Shadow2531 wrote: 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. looks good to me, the only quirk of this would be that you cant choose class=foo bar specifically over class=foo with gebcn(foo bar) but if this is the stated behaviour then i guess that's ok. gebcn(foo bar) should match any element that has *both* foo and bar, but *not necessarily just* foo and bar. If the element doesn't have both foo and bar, the element doesn't match. Therefore, gebcn(foo bar) wouldn't match class=foo because bar is not present. None of the methods of searching in my examples will work as a getElementsByClassAttributeValue. I don't think gebcn is supposed to do that anyway. on a side note, it might also be worth stating that in this case gebcn(foo bar) should only return the class=foo bar element once, not twice (one instance for foo and one instance for bar). just for completeness Correct, each element should only be evaluated once and if just one class you search for in the element's class attribute is not present, the element does not match and it moves on to the next element. That was the idea at least., but maybe my examples don't fully do what I meant or were you just clarifying? :) -- Shadow2531
Re: [whatwg] Empty elements
On Wed, 15 Feb 2006, Tim Altman wrote: May OBJECT and CANVAS be treated as empty elements, i.e. canvas / and object / if there is no fallback content? I don't understand your question. If you mean Can the string 'object/' be treated as an empty element tag, the answer is no. If you mean Can the string 'object' be treated as an empty element tag if there is no matching '/object' then the answer is no according to the current spec, and will probably remain no lest legacy compatibility problems are discovered that require that to change. If you mean Can the string 'object/object' be treated as an empty element then yes, what else would it be treated as? Is fallback content required on OBJECT and CANVAS? Just like with img alt=, the lack of fallback content on either of these would merely indicate that they were semantically neutral and not conveying any extra information. For example: h1The foobar/h1 pThe foobar is a green circle./p pobject data=greencircle.png/object/p There is no fallback here because it would be redundant -- the image paragraph is merely repeating the previous paragraph for emphasis in visual media. -- 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 Wed, 15 Feb 2006, Dan Brickley wrote: Have you considered defining the parser behaviour in terms of XML concepts? What would that mean? Could you give an example of what that would look like? If you do get to the test suite stage, there'll be need for some concrete syntax presumably, to express test outputs in? The output of the parser is a DOM, so the natural form to use as an output concrete syntax is simply a serialised DOM (e.g. an XML file). GRDDL could then say for HTML-ish bytestreams, feed them to the WHATWG algorithm to get XML, and feed that XML to normal GRDDL algorithm to get RDF... I'm with you up to the step where the output is XML, but I fail to see how the next step is something WHATWG would be interested in. Could you expand on this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Empty elements
On Thu, 16 Feb 2006 00:49:15 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Tim Altman wrote: On Wed, 15 Feb 2006 23:48:57 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 15 Feb 2006, Tim Altman wrote: May OBJECT and CANVAS be treated as empty elements, i.e. canvas / and object / if there is no fallback content? I don't understand your question. Let me rephrase: Is it valid for the object and canvas elements use the empty element syntax? HTML: No, XHTML: Yes. Gah! Of course. Thank you. :) If you mean Can the string 'object/' be treated as an empty element tag, the answer is no. You seem to have answered my question here. Why not? Because it is XML syntax, not HTML syntax. According SGML rules, foo/ has a different meaning from the same syntax in XML. According to the new HTML5 parsing rules (due to complete lack of support for SGML), the '/' is an easy parse error and is essentially ignored. Backwards compatibility reasons prevent the XML meaning from being retrofitted into HTML. Got it. -- Tim Altman
Re: [whatwg] HTML5 Parsing spec first draft ready
On Wed, 15 Feb 2006, Dan Brickley wrote: * Ian Hickson [EMAIL PROTECTED] [2006-02-15 23:02+] On Wed, 15 Feb 2006, Dan Brickley wrote: Have you considered defining the parser behaviour in terms of XML concepts? What would that mean? Could you give an example of what that would look like? Expressing things in terms of DOM would be one way, assuming there is a mapping to XML infoset from the DOM Well in that case, it's done. The HTML5 Parser spec is a mapping from a Unicode character stream to a DOM. The output of the parser is a DOM, so the natural form to use as an output concrete syntax is simply a serialised DOM (e.g. an XML file). If your DOM comes with a standard XMLization, we're golden. Sorry I'm not so up to date on DOM stuff (eg. which DOMs have an XMLization defined, etc.). A DOM is a DOM is a DOM. (Well, except for SVG's crazy-ass uDOM nonsense, but let's ignore that.) There are admittedly various ways of serialising a DOM: some are naive and more predictable, but can, in edge, cases end up with ill-formed markup; some are clever and less predictable, but always generate well-formed markup. Any test suite system would have to define its serialisation policy. GRDDL could then say for HTML-ish bytestreams, feed them to the WHATWG algorithm to get XML, and feed that XML to normal GRDDL algorithm to get RDF... I'm with you up to the step where the output is XML, but I fail to see how the next step is something WHATWG would be interested in. Could you expand on this? The next step is for people who find value in RDF's abstract graph structure but find the standard RDF/XML syntax unattractive. GRDDL lets folk deploy using XML or XHTML-based formats of their own devising, but map into RDF using XSLT so that RDF tools (eg. databases, SPARQL query engines) can consume and exploit the data. Ah. Well, HTML5 is defined in terms of a DOM, so GRDDL is presumably, therefore, already supported. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Empty elements
On Wed, 15 Feb 2006, Michael Enright wrote: What about 'foo /' with a space between 'o' and '/' ? There are many legacy pages with that kind of mark-up on br elements and so forth. There are also lot of legacy pages that do it on things like p, sadly. On br it's harmless, and it doesn't help either way to say that it makes an empty element, since it's empty anyway. On other elements, it makes HTML5 UAs have a different DOM that legacy UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Empty elements
BTW, not sure if you have this in the WhatWG parsing spec, but a stray /p (that does not match some opening p) has to be treated like an open p. Also, script src=.../ is actually supported even in HTML by Firefox and Safari. We're stuck with it forever as well, since most of the Dashboard widgets use script src=.../ in HTML. It isn't understood by WinIE or Opera though. You can say we're wrong in the spec, but we won't be able to change it. :( dave ([EMAIL PROTECTED]) On Feb 15, 2006, at 4:16 PM, Ian Hickson wrote: On Wed, 15 Feb 2006, Michael Enright wrote: What about 'foo /' with a space between 'o' and '/' ? There are many legacy pages with that kind of mark-up on br elements and so forth. There are also lot of legacy pages that do it on things like p, sadly. On br it's harmless, and it doesn't help either way to say that it makes an empty element, since it's empty anyway. On other elements, it makes HTML5 UAs have a different DOM that legacy UAs. -- 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
* Ian Hickson [EMAIL PROTECTED] [2006-02-15 23:02+] On Wed, 15 Feb 2006, Dan Brickley wrote: Have you considered defining the parser behaviour in terms of XML concepts? What would that mean? Could you give an example of what that would look like? Expressing things in terms of DOM would be one way, assuming there is a mapping to XML infoset from the DOM (which http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ suggests there is, though perhaps there are DOM version issues here?). If you do get to the test suite stage, there'll be need for some concrete syntax presumably, to express test outputs in? The output of the parser is a DOM, so the natural form to use as an output concrete syntax is simply a serialised DOM (e.g. an XML file). If your DOM comes with a standard XMLization, we're golden. Sorry I'm not so up to date on DOM stuff (eg. which DOMs have an XMLization defined, etc.). GRDDL could then say for HTML-ish bytestreams, feed them to the WHATWG algorithm to get XML, and feed that XML to normal GRDDL algorithm to get RDF... I'm with you up to the step where the output is XML, but I fail to see how the next step is something WHATWG would be interested in. Could you expand on this? The next step is for people who find value in RDF's abstract graph structure but find the standard RDF/XML syntax unattractive. GRDDL lets folk deploy using XML or XHTML-based formats of their own devising, but map into RDF using XSLT so that RDF tools (eg. databases, SPARQL query engines) can consume and exploit the data. I don't expect this to be directly of interest to WHATWG unless WHATWG find value in RDF. Beyond that, just think of it as another potential user of the parser spec. http://www.w3.org/2004/01/rdxh/grddl-xml-demo has some demos of GRDDL in action; http://librdf.org/query has some demos of RDF query using SPARQL, from a toolkit that has GRDDL support. So one use case would be to mix natively RDF content with RDFized microformat markup, so we could write queries whose answers draw on information scattered across both formats and potentially multiple documents. Dan -- 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
* Ian Hickson [EMAIL PROTECTED] [2006-02-13 22:07+] So... The first draft of the HTML5 Parsing spec is ready. I plan to start implementing it at some point in the next few months, to see how well it fares. Any plans for a test suite? eg. pairs of input files and normalised output? (if that makes sense...). Dan
Re: [whatwg] HTML5 Parsing spec first draft ready
+cc: Dan Connolly * Ian Hickson [EMAIL PROTECTED] [2006-02-14 18:41+] 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. Yup, I appreciate it's early days. Discussing some related work (GRDDL) in the W3C SemWeb CG, I was wondering whether there is any way your parser spec could be specified as input for a GRDDL transform. GRDDL provides techniques for transforming XML-based languages (including XHTML) into an RDF representation; typically by reference to an XSLT. If the WHATWG parser spec defined itself in terms of some XML-shaped output, the two should chain nicely together. Have you considered defining the parser behaviour in terms of XML concepts? If you do get to the test suite stage, there'll be need for some concrete syntax presumably, to express test outputs in? GRDDL could then say for HTML-ish bytestreams, feed them to the WHATWG algorithm to get XML, and feed that XML to normal GRDDL algorithm to get RDF... Dan
Re: [whatwg] Empty elements
On Wed, 15 Feb 2006, David Hyatt wrote: BTW, not sure if you have this in the WhatWG parsing spec, but a stray /p (that does not match some opening p) has to be treated like an open p. It's listed as something that we might want to consider if we spec quirks mode. I'm considering just doing it always, but Mozilla doesn't do it in Standards mode. IE does it for a whole bunch more elements than just /p and /br, but I haven't quite worked out the algorithm IE uses to decide when it should do it and when it shouldn't. Mozilla just does it for /p and /br in quirks mode. Safari just does it for /p, but in all modes. BTW, an unmatched /p is treated like p/p, not just like p. Also, script src=.../ is actually supported even in HTML by Firefox and Safari. Safari maybe. Not Firefox: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cscript%20src%3D%22y%22/%3Ex%3C/script%3E This is a compatibility problem for Safari, because it makes Safari incompatible with IE, Mozilla, and Opera. We're stuck with it forever as well, since most of the Dashboard widgets use script src=.../ in HTML. You can say we're wrong in the spec, but we won't be able to change it. :( That, I'm afraid, is your problem. You may wish to consider having a dashboard mode. canvasx/canvas is also parsed differently in Safari than in Mozilla and Opera; again, you may need a Dashboard parse mode if you ever want to switch to the HTML5 way of parsing canvas. (Existing Web content has started relying on the HTML5 way.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Empty elements
David Hyatt wrote: Also, script src=.../ is actually supported even in HTML by Firefox and Safari. Firefox trunk builds do not support unclosed script tags (bug 305873). Gavin
Re: [whatwg] Empty elements
David Hyatt wrote: Also, script src=.../ is actually supported even in HTML by Firefox and Safari. We're stuck with it forever as well, since most of This was a bug in the logic that determined whether or not we'd run scripts. To test this add another inline script (at least one with a /script) down the page a little bit and watch the content in between get eaten. As Gavin mentioned, we've fixed this recently, and thus far the only regression was an extension's default configuration file breaking after depending on this behavior. -- Blake Kaplan
