RE: The key custom elements question: custom constructors?
I've discussed this issue with some of Edge's key parser developers. From a technical ground, we do not have a problem with stopping the parser to callout to author code in order to run a constructor, either during parsing or cloning. For example, in parsing, I would expect that the callout happens after initial instance creation, but before the target node is attached to the DOM tree by the parser. Having put my support in for this design, which I believe to be the most straightforward approach that most closely matches how the platform itself works, and which would not be a problematic issue for our implementation, I did have a chance to discuss this briefly with Alex Russell, who felt that running synchronous author code at such early stages in the loading pipeline (e.g., while initial parsing due to a previously encountered document.registerElement call was an anti-pattern that he'd like to avoid. He is a strong supporter of the proto-swizzle technique that happens later with retro-active upgrades to previously-seen custom elements. I am sympathetic to this concern, but have my own reservations about the proto-swizzle technique. -Original Message- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Thursday, July 16, 2015 2:45 AM To: public-webapps Subject: The key custom elements question: custom constructors? Hi all, Ahead of next week's F2F, I'm trying to pull together some clarifying and stage-setting materials, proposals, lists of open issues, etc. In the end, they all get blocked on one key question: **Is it OK to run author code during parsing/cloning/editing/printing (in Gecko)/etc.?** If we allow custom elements to have custom constructors, then those must run in order to create properly-allocated instances of those elements; there is simply no other way to create those objects. You can shuffle the timing around a bit: e.g., while cloning a tree, you could either run the constructors at the normal times, or try to do something like almost-synchronous constructors [1] where you run them after constructing a skeleton of the cloned tree, but before inserting them into the tree. But the fact remains that if custom elements have custom constructors, those custom constructors must run in the middle of all those operations. We've danced around this question many times. But I think we need a clear answer from the various implementers involved before we can continue. In particular, I'm not interested in whether the implementers think it's technically feasible. I'd like to know whether they think it's something we should standardize. I'm hoping we can settle this on-list over the next day or two so that we all come to the meeting with a clear starting point. Thanks very much, and looking forward to your replies, -Domenic [1]: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html
Re: The key custom elements question: custom constructors?
On 07/16/2015 03:45 AM, Domenic Denicola wrote: Hi all, Ahead of next week's F2F, I'm trying to pull together some clarifying and stage-setting materials, proposals, lists of open issues, etc. In the end, they all get blocked on one key question: **Is it OK to run author code during parsing/cloning/editing/printing (in Gecko)/etc.?** As of now, clone-document-for-printing is a gecko implementation detail and shouldn't limit anything here. I think we'll just clone whatever data is needed to be cloned without running any scripts, since scripts won't run in the static clone anyway. (but from implementation point of view I can say clone-document-for-printing is rather nice feature, simplified Gecko's printing setup quite a bit ;)) Running author code during cloneNode(true) can be very hard to spec and implement correctly, so I'd prefer if we could avoid that. If we allow custom elements to have custom constructors, then those must run in order to create properly-allocated instances of those elements; there is simply no other way to create those objects. You can shuffle the timing around a bit: e.g., while cloning a tree, you could either run the constructors at the normal times, or try to do something like almost-synchronous constructors [1] where you run them after constructing a skeleton of the cloned tree, but before inserting them into the tree. But the fact remains that if custom elements have custom constructors, those custom constructors must run in the middle of all those operations. We've danced around this question many times. But I think we need a clear answer from the various implementers involved before we can continue. In particular, I'm not interested in whether the implementers think it's technically feasible. I'd like to know whether they think it's something we should standardize. It is also about someone writing a good spec for this all - no one ever managed to spec MutationEvents properly, and running author code during cloneNode(true) is at least as hard problem to solve. -Olli I'm hoping we can settle this on-list over the next day or two so that we all come to the meeting with a clear starting point. Thanks very much, and looking forward to your replies, -Domenic [1]: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html
Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
Hi all,
I'm developing an web-based editor which can edit HTML documents locally
(stored in indexedDB).
An issue I encountered is that there is no reliable way to ensure that
at most one editor instance (an instance is a web page) can open a
document at the same time.
* An editor instance may create a flag entry in indexedDB or
localStorage for each opened document to indicate this document is
locked, and remove this flag when the document is closed. However, if
the editor is closed forcibly, this flag won't be removed, and the
document can't be opened any more!
* An editor instance may use storage event of localStorage to ask is
this document has been opened by any other editor instance. If there is
no response for a while, it can open the document. However, storage
event is async so we are not sure about how long the editor has to wait
before opening the document.
* IndexedDB and FileHandle do have locks, but such locks can only live
for a short time, so can't lock an object during the entire lifetime of
an editor instance.
In a native editor application, it may use file locking
(https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
So maybe it is valuable to add similar locking mechanism to
indexedDB/web storage/FileHandle?
I propose a locking API of web storage:
try {
localStorage.lock('file1.html');
myEditor.open('file1.html'); // open and edit the document
} catch (e) {
alert('file1.html is already opened by another editor');
}
Storage.lock() lock an entry if it has not been locked, and throw if it
has been locked by another page.
The locked entry is unlocked automatically after the page holding the
lock is unloaded. It can also be unlocked by calling Storage.unlock().
What do you think?
Regards,
Duan Yao
Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
Based on similar feedback, I've been noodling on this too. Here are my
current thoughts:
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
Feedback welcome - I was planning to send this around shortly anyway.
On Wed, Jul 15, 2015 at 3:07 AM, 段垚 duan...@ustc.edu wrote:
Hi all,
I'm developing an web-based editor which can edit HTML documents locally
(stored in indexedDB).
An issue I encountered is that there is no reliable way to ensure that at
most one editor instance (an instance is a web page) can open a document at
the same time.
* An editor instance may create a flag entry in indexedDB or localStorage
for each opened document to indicate this document is locked, and remove
this flag when the document is closed. However, if the editor is closed
forcibly, this flag won't be removed, and the document can't be opened any
more!
* An editor instance may use storage event of localStorage to ask is this
document has been opened by any other editor instance. If there is no
response for a while, it can open the document. However, storage event is
async so we are not sure about how long the editor has to wait before
opening the document.
* IndexedDB and FileHandle do have locks, but such locks can only live for
a short time, so can't lock an object during the entire lifetime of an
editor instance.
In a native editor application, it may use file locking (
https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
So maybe it is valuable to add similar locking mechanism to indexedDB/web
storage/FileHandle?
I propose a locking API of web storage:
try {
localStorage.lock('file1.html');
myEditor.open('file1.html'); // open and edit the document
} catch (e) {
alert('file1.html is already opened by another editor');
}
Storage.lock() lock an entry if it has not been locked, and throw if it
has been locked by another page.
The locked entry is unlocked automatically after the page holding the lock
is unloaded. It can also be unlocked by calling Storage.unlock().
What do you think?
Regards,
Duan Yao
[Bug 26676] Non-fullscreen documents can end up with non-empty fullscreen element stacks
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26676 Bug 26676 depends on bug 27865, which changed state. Bug 27865 Summary: Merge fullscreen element stack into top layer https://www.w3.org/Bugs/Public/show_bug.cgi?id=27865 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27865] Merge fullscreen element stack into top layer
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27865 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/766dc872bcf26c012549f7bdfde21c46bebba40c was the last commit needed here I think. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27863] Not need to specify moving element in top layer and fullscreen stack
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27863 Bug 27863 depends on bug 27865, which changed state. Bug 27865 Summary: Merge fullscreen element stack into top layer https://www.w3.org/Bugs/Public/show_bug.cgi?id=27865 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: Informal Service Worker working session
On Sat, Jul 4, 2015 at 7:26 AM, Alex Russell slightly...@google.com wrote: As many SW participants are going to be in town for the WebApps F2F on the 21st, Google San Francisco is hosting a working day, 9am-5pm PST on July 20th to work through open issues and discuss future work. If you're attending, or would like to, simply RSVP here: http://doodle.com/hqm3ga8pfepidy7r Alex, Thanks for hosting! In preparation for the meeting we've come up with a rough list of things we'd like to discuss next week: - Clarify behavior in places where the fetch spec has not been integrated into other specs yet. For example, intercepting something that is currently same-origin with a synthetic or CORS response, how interception works with CSP, etc. Clearly Chrome has done something for these cases and we'd like to be compatible where possible. - Consider adding a foreign fetch feature to communicate with a SW on a different origin. Straw man of the concept can be found at https://wiki.whatwg.org/wiki/Foreign_Fetch . - Discuss navigator.connect(). In particular, can the use cases motivating navigator.connect() be satisfied with a simpler solution like the foreign fetch concept. - Discuss how to make it easier to use multiple service workers for the same site. For example, currently its difficult to update two service workers coherently. One will always be a newer version than the other. - Discuss how to handle heavy-weight processing for things like background sync without introducing fetch event latency. This could be using multiple service workers (with issues above addressed) or possible supporting SharedWorker, etc. - Consider using the service worker script URL to identify the service worker instead of its scope. This would move us closer to not requiring a scope for service workers that aren't handling fetch events. - Consider allowing specific features, like fetch and push, to be specified at registration time. Again, the goal is to get away from the current situation where registering a service worker immediately implies fetch event handling. - Consider providing an API for creating a service worker without going through the installation life cycle. - Share information about how we plan to avoid abuse of push and background sync events. Anyway, we just wanted to give people a chance to think about some of this before we meet. Obviously we may not have time to cover all of this in a day, but it would be nice to cover any contentious bits. Thanks again and see you all next week. Ben
Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
Yeah, I think a standalone primitive for asynchronous atomics. The
big risk is of course that deadlocks can occur, but there's no real
way to completely avoid that while keeping a flexible platform. These
deadlocks would be asynchronous, so no thread will hang, but you can
easily end up with two pages looking hung to the user.
The best thing that I think we can do to help here is to enable pages
to issue a single function call which grabs multiple locks.
We could also enable registering a callback which is called when the
platform detects a deadlock. However we won't always be able to detect
deadlocks, so I'm not sure that it's a good idea.
I also don't have enough experience to know which atomics are worth
exposing, and which ones we should leave to libraries.
/ Jonas
On Wed, Jul 15, 2015 at 10:12 AM, Joshua Bell jsb...@google.com wrote:
Based on similar feedback, I've been noodling on this too. Here are my
current thoughts:
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
Feedback welcome - I was planning to send this around shortly anyway.
On Wed, Jul 15, 2015 at 3:07 AM, 段垚 duan...@ustc.edu wrote:
Hi all,
I'm developing an web-based editor which can edit HTML documents locally
(stored in indexedDB).
An issue I encountered is that there is no reliable way to ensure that at
most one editor instance (an instance is a web page) can open a document at
the same time.
* An editor instance may create a flag entry in indexedDB or localStorage
for each opened document to indicate this document is locked, and remove
this flag when the document is closed. However, if the editor is closed
forcibly, this flag won't be removed, and the document can't be opened any
more!
* An editor instance may use storage event of localStorage to ask is this
document has been opened by any other editor instance. If there is no
response for a while, it can open the document. However, storage event is
async so we are not sure about how long the editor has to wait before
opening the document.
* IndexedDB and FileHandle do have locks, but such locks can only live for
a short time, so can't lock an object during the entire lifetime of an
editor instance.
In a native editor application, it may use file locking
(https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
So maybe it is valuable to add similar locking mechanism to indexedDB/web
storage/FileHandle?
I propose a locking API of web storage:
try {
localStorage.lock('file1.html');
myEditor.open('file1.html'); // open and edit the document
} catch (e) {
alert('file1.html is already opened by another editor');
}
Storage.lock() lock an entry if it has not been locked, and throw if it
has been locked by another page.
The locked entry is unlocked automatically after the page holding the lock
is unloaded. It can also be unlocked by calling Storage.unlock().
What do you think?
Regards,
Duan Yao
[Bug 26677] Clarify when :fullscreen applies
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26677 Philip Jägenstedt phil...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Philip Jägenstedt phil...@opera.com --- The spec now says what I asked for: The :fullscreen pseudo-class must match any element that is that element's node document's fullscreen element. -- You are receiving this mail because: You are on the CC list for the bug.
