Unless I'm misunderstanding something, I believe this actually is - or at
least touches upon - several questions in disguise:
.) Do we want to allow decoration of elements that are already in the DOM
tree?
- which is for all intents and purposes a corollary of:
.) Do we allow calling of new
On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote:
Here is a quick first cut:
How about use cases like these:
- Extension that wants to inspect input type=password and warn you
when you are entering you password in an insecure form (from abarth
earlier in the
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote:
On the other hand, it seems likely that some of these xdash names will
come into multi-party use. For example, the following use cases
involve xdash names chosen by one party and then used by another:
From the discussion about x- prefixed names another question crossed my
mind: Suppose an author defines a component, but doesn't register a tag
name. AFAICT, at this point nothing prevents him from inserting such a new
element into the DOM. E.g.:
div id=div/div
script
function MyNewElement()
I think HTMLElement.call should throw if there’s not an associated tag name.
However exactly how that association happens, I am not sure.
JavaScript can’t rely on the 'constructor' property. Shadowing the
tagName attribute on the prototype is not ideal, because it may be
mutable and it would be
On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner
rolandstei...@google.com wrote:
On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote:
Here is a quick first cut:
How about use cases like these:
- Extension that wants to inspect input type=password and warn you
when you
On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner
rolandstei...@google.com wrote:
Unless I'm misunderstanding something, I believe this actually is - or at
least touches upon - several questions in disguise:
.) Do we want to allow decoration of elements that are already in the DOM
tree?
If by
On Fri, Aug 26, 2011 at 1:07 AM, Roland Steiner
rolandstei...@google.com wrote:
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote:
On the other hand, it seems likely that some of these xdash names will
come into multi-party use. For example, the following use cases
involve
That works, but what is the advantage? And .push/.pop or other
mutating functions wouldn't work.
All mutable functions will work (forEach, map, etc.) and bring a better
expressiveness to the code.
Not if he 'this' object is a NodeList.
Yes, sorry I meant all “immutable” functions
Eliot and I went through the spec and identified the various issues stated in
it. Below is our opinion on each of the open issues based on our understanding
of the text. Based on this, there doesn't seem to be anything major that is
blocking our ability to successfully move this spec to Last
-- What if target is removed from DOM, or is not currently in DOM? --
Additional issues from Olli Pettay on w3 bug.
I believe mouse lock should fail to acquire if the target is not in the DOM
tree, and should be exited if the target of an existing lock is removed from
the tree.
-- Are user
We looked at the spec to see what it would take to be able to support
multi-column keys on primary keys indexes and we found some inconsistencies
that need to be addressed. Below is our proposal/assumptions on how to
constrain the problem and what needs to be updated in the spec to support
Awesome list!
1. Sections: 3.1.2 Object Store
Issue Text: specify that generators are not shared between stores.
Feedback: We prefer this approach. We should state this in the spec and
remove the issue.
Agreed. This was the intent, but it might not be spelled out.
Generators are not
13 matches
Mail list logo
