Re: [Selection] Should selection.getRangeAt return a clone or a reference?
While I agree that it's nice, I have mild preference to return a clone. As Olii said, changing from clone to live would involve quite a bit of code. I feel sorry for already implemented people though. I also guess that we need to ask more work to the spec editor to support the liveness, such as: - What will happen to the live-object on removeAllRanges()? - Would the live-object keeps the same reference for removeAllRanges() + addRanges()? - It may never happen, but when multiple ranges are supported, are they bound to index? Specing them in detail and writing tests for all these cases would be quite a bit of work. /koji On Wed, Jan 7, 2015 at 9:02 AM, Tim Down t...@timdown.co.uk wrote: For what it's worth as a user of the range and selection APIs, updating a live range is convenient and preferable, but since this has never worked in all browsers, I never do it and have never recommended it to anyone else. Therefore if Gecko changes, nothing really changes for me, so I don't care. Knock yourself out, Mozilla. Tim On 6 January 2015 at 22:32, Ryosuke Niwa rn...@apple.com wrote: https://github.com/w3c/selection-api/issues/40 Trident (since IE10) and Gecko both return a live Range, which can be modified to update selection. WebKit and Blink both return a clone Range so that any changes to the Range doesn't update the selection. It appears that there is a moderate interest at Mozilla to change Gecko's behavior. Does anyone have a strong opinion about this? - R. Niwa
Re: ES6 and upgrading custom elements
On Wed, Jan 7, 2015 at 5:53 AM, Domenic Denicola d...@domenic.me wrote: ... all instances of MyInputElement will get all internal slots and other exotic behavior of HTMLInputElement. That's why I tried to scope this thread to upgrading and not the script side. The main question is how you tie MyInputElement to something like my-input and have that actually work. It seems Dimitri's answer is that you don't, you use input is=my-input in combination with a (delayed) prototype mutation and creation callback. And you use createElement(input, my-input) or the constructor on the script side of things. Which is that the HTML standard should just define that `HTMLInputElement.extends = input`. We could have that I guess, but it still doesn't help with upgrading, does it? -- https://annevankesteren.nl/
Defining a constructor for Element and friends
The important local slots for an element are its local name, prefix, and namespace. I believe that for certain operations in HTML it is also important to be able to instantiate an element along with several attributes given by the parser so that when the first initialize operations runs it has access to all of those. Though it seems HTML could abstract over that somehow. The main tricky thing here I think is whether it is acceptable to have an element whose name is a, namespace is the HTML namespace, and interface is Element. I.e. can we break the invariant that the combination of a and HTML namespace is always HTMLAnchorElement. If we can break that invariant it seems rather easy to build the hierarchy. The HTMLElement constructor would only take a local name and always have a null prefix and HTML namespace. And HTMLAnchorElement would always be a. HTMLQuoteElement could accept an enum and we could even add dedicated constructors for q and blockquote (provided the web allows). -- https://annevankesteren.nl/
Re: Defining a constructor for Element and friends
On 1/7/15 6:17 AM, Anne van Kesteren wrote:
The main tricky thing here I think is whether it is acceptable to have
an element whose name is a, namespace is the HTML namespace, and
interface is Element.
That depends on what you mean by interface is Element.
If you mean that it has all the internal slots HTMLAnchorElement has but
its prototype is Element.prototype, I think that may be fine. Libraries
might get confused if you pass them elements like this, but that just
comes down to don't create elements like this as a guideline, right?
If you mean not having the internal slots HTMLAnchorElement has, then
that would involve a good bit of both specification and implementation
work. Specifically:
1) Pretty much the entire HTML spec is written in terms of tag names,
and the operations it performs often assume some sort of state being
stored on elements with those tag names. Conceptually this is being
stored in internal slots (though of course in actual implementations
slots can mean hashtable entries in some hashtable or whatnot).
Significant spec work would need to happen to deal with situations where
the element has some tagname but not the corresponding internal slots.
2) In specifications, there are assumptions about particular tag names
having particular internal slots. For example, you often get code like
this (not actual code in either one, but intended to get the flavor
across) at least in WebKit and Gecko:
void doWhatever(Element* element) {
if (element-isHTML() element-tagName() == input) {
HTMLInputElement* input = static_castHTMLInputElement*(element);
// Do stuff with input here.
}
}
If we can have HTML elements which have the input tag name but aren't
represented by a subclass of the C++ HTMLInputElement in the above code,
you get a security bug. So codebases would have to be audited for all
instances of this and similar patterns. I just did a quick check in
Gecko, and we're looking at at least 500 callsites just in C++. There
are probably more in privileged JavaScript that make assumptions about
things based on tagname...
This is why the custom elements spec ended up with the is=... business
for extending nontrivial HTML elements. :(
So just to check, which of these two invariant-violations are we talking
about here?
If we can break that invariant it seems rather easy to build the
hierarchy. The HTMLElement constructor would only take a local name
and always have a null prefix and HTML namespace.
I think that's fine in a world where we still create an
HTMLAnchorElement under the hood if you do new HTMLElement('a') but
just give it HTMLElement.prototype as the proto.
And HTMLAnchorElement would always be a. HTMLQuoteElement could accept
an enum and we could even add dedicated constructors for q and
blockquote (provided the web allows).
Yeah, this would make sense to me.
-Boris
FYI: Deep linking
FYI. If anyone thinks WebApps should be involved in this area, please speak (f.ex. what is the connection, what role would WebApps have, etc.). -Thanks, ArtB Forwarded Message Subject:Deep linking Resent-Date:Tue, 06 Jan 2015 10:45:04 + Resent-From:public-web-mob...@w3.org Date: Tue, 06 Jan 2015 11:44:48 +0100 From: Dominique Hazael-Massieux d...@w3.org To: public-web-mob...@w3.org Hi, In the past few months, several efforts have emerged to try to make native apps get some of the benefits of the Web (inter-linking), as well as to make them more integrated in the Web (seamless transition between browser-based and native-based views of the Web). Google has app indexing: https://developers.google.com/app-indexing/webmasters/app Quixey has appURLs: http://appurl.org/ Facebook has AppLinks: https://developers.facebook.com/blog/post/2014/04/30/app-links http://applinks.org/ URX has omnilinks http://blog.urx.com/urx-blog/omnilinks-app-links-and-the-state-of-mobile These efforts have also received attention from the press: http://recode.net/2014/10/28/how-deep-linking-could-fix-mobile/ http://www.nytimes.com/2015/01/06/technology/tech-companies-look-to-break-down-walls-between-apps.html?ref=technology Given the number of competing proposals in this space, and given they're only as useful as they get widespread, it feels to me this space is probably ripe for some standardization effort, or at least pre-standardization. It's also an interesting twist to the usual “native vs Web” — it is closer to “native ♥ Web”, with benefits for all. I'm looking for feedback on the topic, and potential interest in contributing efforts in this space. Follow up actions could be a community group, or even a workshop if we feel this type of topic requires broader visibility from the community. Thanks, and happy new year to all! Dom
Re: Defining a constructor for Element and friends
On Wed, Jan 7, 2015 at 2:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: If you mean not having the internal slots HTMLAnchorElement has, then that would involve a good bit of both specification and implementation work. That is what I meant. Otherwise in order to support new Element() you'd have to support an ever growing set of more specific objects as well and layering is out of the window. However, that does indeed seem like a lot of work and it's not clear whether that actually pays off in the end :-( -- https://annevankesteren.nl/
[Bug 27785] New: [Shadow]: broken link in draft spec section 9.3
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27785 Bug ID: 27785 Summary: [Shadow]: broken link in draft spec section 9.3 Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: m1...@earthlink.net QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 Section 9.3 The content element Context Where flow content is expected. flow content is a link to this URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#flow-content-0 But it's broken. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27780] New: [Custom]: All Algorithms in One Diagram
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27780 Bug ID: 27780 Summary: [Custom]: All Algorithms in One Diagram Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Per this diagram the prototype is changed after any callbacks are invoked but that is wrong per the prose. -- You are receiving this mail because: You are on the CC list for the bug.
RE: ES6 and upgrading custom elements
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren That's why I tried to scope this thread to upgrading and not the script side. The main question is how you tie MyInputElement to something like my-input and have that actually work. It seems Dimitri's answer is that you don't, you use input is=my-input in combination with a (delayed) prototype mutation and creation callback. And you use createElement(input, my-input) or the constructor on the script side of things. Oh my goodness, I'm sorry. I completely misunderstood what was meant by upgrading. My fault entirely, as it's a well-defined custom elements term. I see the problem now. I'll try to think on it harder and get back to you. In the meantime, apologies for derailing the thread.
Re: Defining a constructor for Element and friends
On 1/7/15 9:51 AM, Anne van Kesteren wrote: That is what I meant. Otherwise in order to support new Element() you'd have to support an ever growing set of more specific objects as well and layering is out of the window. Do you mean layering of implementations or specifications? For specifications, here's one way this could work with reasonable layering. DOM provides the following bits: 1) A registry mapping (namespace, localname) pairs to abstract operations that allocate an object. 2) Abstract operations that can be used by specifications built on top of DOM to register abstract operations in this registry. 3) An abstract operation that takes a list of internal slot names and returns an object which has those internal slots, plus the internal slots all elements have, plus probably the ordinary object internal slots from ES6, depending on whether Web IDL assumes these are ordinary objects. I thought ES6 had this sort of abstract operation already, but I don't see anything like it; in any case the only issue here is that this requires implementations of DOM and specifications built on top of it to agree internally on what internal slot means for elements, I agree. Specifications that define elements on top of DOM provide the following bits: 4) An abstract operation that creates an uninitialized version of their element, via calling the thing defined in #3. 5) Registration of the abstract operation defined in #4 with the registry defined in #1, whether that happens at global-setup time or when the element definition is encountered or whatever. An implementation that wants to just implement core DOM but not things built on on top of it can skip all of this machinery. An implementation that wants to support DOM but not everything on top of it (e.g. support MathML but not HTML or something) just supports the bits it wants and the registry ends up not having stuff in it that it has in other implementations. Seems ok to me. Now some questions: * Did I cover your concern about have to support an ever growing set of more specific objects? If not, can you explain what the concern is? * Without a mechanism like the above, how would one go about supporting document.createElement(NS) as it exists on the web. However, that does indeed seem like a lot of work and it's not clear whether that actually pays off in the end :-( That's hard to say without knowing what the desired payoff is. -Boris
[Bug 27727] Remove DOMError from IDB
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27727 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@gmail.com, ||jsb...@google.com Resolution|--- |LATER --- Comment #1 from Joshua Bell jsb...@google.com --- Tentatively resolving as LATER as we'd do this in a follow-up version of the spec (e.g. IDB v2), but I'll let others wrangle W3C process and inter-spec reference requirements. (And yeah, would be nice to eliminate DOMError, but it's shipping in browsers now so like eliminating DOMStringList I'm not sure it'll be as easy as dom.spec.whatwg.org implies. At least it has no methods.) -- You are receiving this mail because: You are on the CC list for the bug.
