Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/31/2013 04:13 PM, Boris Zbarsky wrote: In particular, I don't believe browser vendors typically run W3C test suites en masse regularly, Just going to note here that James Graham is, in fact, working on doing that for Mozilla. HTH Ms2ger
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Hi Tim,
On 10/19/2013 07:03 PM, Tim Streater wrote:
On 18 Oct 2013 at 22:56, Boris Zbarsky posted, inter alia,
this code:
[1] The testcase:
document.write("<svg id='root' width='0' height='0'>");
for (var i = 0; i < 100; ++i) {
document.write("<rect/>");
}
document.write("<rect id='test'/>");
document.write("</svg>\n");
var node;
var count = 20;
function doTests(root, elementId, descQS, descQSNoConcat, descGEBI) {
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.querySelector("#" + elementId);
var stop = new Date;
document.writeln(descQS + ((stop - start) / count * 1e6));
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.querySelector("#test");
var stop = new Date;
document.writeln(descQSNoConcat + ((stop - start) / count * 1e6));
var start = new Date;
for (var i = 0; i < count; ++i)
node = root.getElementById(elementId);
var stop = new Date;
document.writeln(descGEBI + ((stop - start) / count * 1e6));
}
var root = document.getElementById("root");
var start = new Date;
for (var i = 0; i < count; ++i)
node = document.getElementById("test");
var stop = new Date;
document.writeln("document.getElementById: " + ((stop - start) /
count * 1e6));
doTests(root, "test",
"In-tree querySelector: ",
"In-tree querySelector, no string concat: ",
"In-tree getElementById: ");
root.remove();
doTests(root, "test",
"Out-of-tree querySelector: ",
"Out-of-tree querySelector, no string concat: ",
"Out-of-tree getElementById: ");
I've tested this here on five browsers and it runs to completion Ok
apart from iCab, which didn't like root.remove so I did that bit
longhand. But I'm left confused. The other day I ranted about needing
to use a document fragment and having to use querySelector on a table
body. Now this code appears to imply that I need neither and could
have used getElementById all along, since your application of
getElementById above is mostly not to a document. I'm sure that when
I tested that, a year or so back, it didn't work. Could you
elucidate?
Quoting part of the original email you trimmed:
Luckily, we have SVGSVGElement.prototype.getElementById available to
compare to Element.prototype.querySelector.
That is, getElementById is available on |svg| elements in the SVG namespace.
HTH
Ms2ger
Re: [whatwg] Pull requests for HTML5 spec?
On 05/14/2013 09:41 AM, Michael Day wrote: Hi Silvia, If you want to contribute to the WHATWG spec, you should register a bug on https://www.w3.org/Bugs/Public/describecomponents.cgi?product=WHATWG . WHATWG patches eventually get cherry-picked into the W3C spec, too, unless there is strong opposition in the HTML WG. If the WHATWG spec is hosted on Subversion, I guess that means pull requests to that branch on Github will be ignored? Indeed. You can always send Hixie a patch by email, if you like making changes yourself. HTH Ms2ger
Re: [whatwg] Standardizing Console object
On 12/18/2012 06:34 PM, Rick Waldron wrote: Sent to: public-script-coord, whatwg Has there been any work or discussion with regard to standardizing the Console object? https://developers.google.com/chrome-developer-tools/docs/console https://getfirebug.com/wiki/index.php/Console_API http://msdn.microsoft.com/library/gg589530 http://www.opera.com/dragonfly/documentation/console/ http://developer.apple.com/library/safari/#documentation/appleapplications/Conceptual/Safari_Developer_Guide/DebuggingYourWebsite/DebuggingYourWebsite.html#//apple_ref/doc/uid/TP40007874-CH8-SW31 Mike Smith has done some work on this: http://sideshowbarker.github.com/console-spec/ HTH Ms2ger
Re: [whatwg] DOMTokenList enable
On 08/01/2012 11:07 PM, Erik Arvidsson wrote:
Most JS libraries has a way to add or remove a class name based on a
boolean parameter.
I'm suggesting we add a way to do this to DOMTokenList. The semantics
would be the same as the following pure JS implementation.
DOMTokenList.prototype.enable = function(name, value) {
value ? this.add(name) : this.remove(name);
};
I filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18463> to track
this proposal.
HTH
Ms2ger
Re: [whatwg] Why isn't the "pattern" attribute applied to ?
Hi Brenton,
On 02/10/2012 11:39 AM, brenton strine wrote:
Regarding the an input with type in the "number" state, the spec states
that the "pattern" attribute "must not be specified and do[es] not
apply<http://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply>
to
the element". (
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
)
Why is it specifically blocked? Doesn't that encourage the use of a less
semantic "text" input type for numbers that need to be validated beyond
simple max and min?
What if you want the number to be either 13 or 16 digits long, as with a
credit card
pattern="(\d{5}([\-]\d{4})?)"
or you want a US ZIP or ZP4 code which can either be n or n-
pattern="(\d{5}([\-]\d{4})?)"
To get the pattern to validate, I have to (non-semantically) change the
input to the text state? I much prefer the current behavior of Firefox
(tested 9 and 10) which does validate the pattern.
Using input type=number for those cases is wrong. You would not use a
credit card number or a ZIP code in calculations. (In fact, in the
United Kingdom, post codes contain letters.)
input type=number is meant to be used for numbers, rather than for
strings that happen to contain mostly numbers. The specification does
indeed require a *more* semantically correct input type=text for those
cases.
The reason that Firefox validates the pattern is that it currently does
not implement input type=number (patches welcome). Instead, it
implements the fallback behaviour defined in the specification, i.e.,
treat unknown 'type' values as 'text'—which causes the pattern attribute
to apply. Using input type=number pattern=... will break as soon as
Firefox correctly implements the feature.
HTH
Ms2ger
Re: [whatwg] Should script run if it comes from a HTML fragment?
Ms2ger wrote: Ryosuke Niwa wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking wrote: You looking at only part of what Henri said. He also pointed to http://www.w3.org/Bugs/Public/show_bug.cgi?id=11191 which is a request to change HTML5 so that createContextualFragment can specify that scripts should remain executable. However, this request has not been granted yet. The specification [1] now states: > Mark all scripts in /new children/ as "already started". This should have said "Unmark". Unfortunately, this update hasn't propagated to html5.org yet, but please take this (unmarked, to be executed) as the current status. Apologies for any confusion caused. Ms2ger [1] http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
Re: [whatwg] Should script run if it comes from a HTML fragment?
Ryosuke Niwa wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking wrote: You looking at only part of what Henri said. He also pointed to http://www.w3.org/Bugs/Public/show_bug.cgi?id=11191 which is a request to change HTML5 so that createContextualFragment can specify that scripts should remain executable. However, this request has not been granted yet. The specification [1] now states: > Mark all scripts in /new children/ as "already started". I hope this clarifies my intention. Ms2ger [1] http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
