Re: [custom-elements] Steps inside HTMLElement's constructor

[Ryosuke Niwa]

> On Feb 22, 2016, at 10:46 PM, Ryosuke Niwa  wrote:
> 
> Here are steps to construct a custom element as agreed during Jan F2F as I 
> promised to write down [1] [2]:

There's a very appealing alternative to this, which doesn't involve having a 
element construction stack per definition.

We add an extra argument, let us call it exoticNewTarget, to [[Construct]] 
internal method [7], which is initially Null.  More precisely, [[Construct]] 
now takes arguments (a List of any, Object, Object) where the third argument is 
a newly created exotic object.

Add a new environmental records field, [[ExoticNewTarget]], which is either an 
Object or undefined. If this Environment Record was created by the 
[[Construct]] internal method, [[ExoticNewTarget]] is the value of the 
[[ExoticNewTarget]] exoticNewTarget parameter. Otherwise, its value is 
undefined.

Add a new abstract operation GetExoticNewTarget(), which performs the following 
steps:
1. Let envRec be GetThisEnvironment().
2. Assert: envRec has a [[ExoticNewTarget]] field.
3. Return envRec.[[ExoticNewTarget]].

We also modify step 7 of runtime semantics of SuperCall from:
7. Let result be Construct(func, argList, newTarget).
to
7. Let result be Construct(func, argList, newTarget, GetExoticNewTarget()).

With these simple changes, we can simplify the algorithm as follows and it 
would ALWYAS construct the right element:


== Custom Element Construction Algorithm ==

Input
 NAME, the custom element name.
 DOCUMENT, the owner document for new custom element.
 EXOTIC-TARGET, the target Element to be constructed / upgraded.
OUTPUT
 ELEMENT, new custom element instance.
 ERROR, could be either "None", "NotFound", "InvalidStateError", or an 
ECMAScript exception.

1. Let ERROR be "None".
2. Let REGISTRY be the (custom element) registry of DOCUMENT.
3. If DOCUMENT is an HTML document, let NAME be converted to ASCII lowercase.
4. Let DEFINITION be the element definition of with the local name, NAME, in 
REGISTRY.
5. If there is no matching definition, set ERROR to "NotFound" and terminate 
these steps.
7. Invoke the [[Construct]] internal method [3] on the custom element 
interface, INTERFACE, of DEFINITION
   with (INTERFACE, an empty list, INTERFACE, EXOTIC-TARGET)
9. If the [[Construct]] invocation resulted in an exception, set ERROR to the 
raised exception, and terminate these steps.
10. Otherwise, let ELEMENT be the result of the invocation.
11. If ELEMENT is not an instance of INTERFACE with local name, NAME, set ERROR 
to "InvalidStateError", and terminate these steps.


== HTMLElement constructor ==

1. Let TARGET be GetNewTarget(). [4]
2. Let EXOTIC-TARGET be GetExoticNewTarget().
3. If EXOTIC-TARGET is not undefined, return EXOTIC-TARGET and terminate these 
steps.
4. Let DOCUMENT be the associated document of the global object (the result of 
GetGlobalObject() [5]).
5. Let REGISTRY be the (custom element) registry of DOCUMENT.
6. Let DEFINITION be the element definition with the element interface, TARGET, 
in REGISTRY.
7. If there is no matching definition, throw TypeError and terminate these 
steps.
8. Let NAME be the local name of DEFINITION.
9. Return a new element that implements HTMLElement, with no attributes, 
namespace set to the HTML namespace,
   local name set to NAME, and node document set to DOCUMENT.

[7] http://www.ecma-international.org/ecma-262/6.0/#table-6
[8] 
http://www.ecma-international.org/ecma-262/6.0/#sec-super-keyword-runtime-semantics-evaluation

[custom-elements] Steps inside HTMLElement's constructor

[Ryosuke Niwa]

Hi all,

Here are steps to construct a custom element as agreed during Jan F2F as I 
promised to write down [1] [2]:

Modify http://w3c.github.io/webcomponents/spec/custom/#dfn-element-definition 
as follows:
The element definition describes a custom element and consists of:

 * custom element type,
 * local name,
 * namespace,
 * custom element interface,
 * lifecycle callbacks, and
 * element construction stack.

Each element construction stack is initially empty, and each entry is an 
instance of Element or a "AlreadyConstructed" marker.

Non-Normative Note: We need a stack per element definition to allow 
construction of other custom elements inside a custom element's constructor. 
Without such a stack per element definition, we would end up walking through 
entries in the stack to find the "right" entry.  Implementors are free to take 
such an approach to minimize the memory usage, etc..., but there are a lot of 
edge cases that need to be taken care of, and it's not a great way to spec an 
interoperable behavior.


== Custom Element Construction Algorithm ==

Input
  NAME, the custom element name.
  DOCUMENT, the owner document for new custom element.
  EXOTIC-TARGET, the target Element to be constructed / upgraded.
OUTPUT
  ELEMENT, new custom element instance.
  ERROR, could be either "None", "NotFound", "InvalidStateError", or an 
ECMAScript exception.

1. Let ERROR be "None".
2. Let REGISTRY be the (custom element) registry of DOCUMENT.
3. If DOCUMENT is an HTML document, let NAME be converted to ASCII lowercase.
4. Let DEFINITION be the element definition of with the local name, NAME, in 
REGISTRY.
5. If there is no matching definition, set ERROR to "NotFound" and terminate 
these steps.
6. Otherwise, push a new entry, EXOTIC-TARGET, to the element construction 
stack of DEFINITION.
7. Invoke the [[Construct]] internal method [3] on custom element interface of 
DEFINITION.
8. Pop the entry from the element construction stack of DEFINITION.
9. If the [[Construct]] invocation resulted in an exception, set ERROR to the 
raised exception, and terminate these steps.
10. Otherwise, let ELEMENT be the result of the invocation.
11. If ELEMENT is not the same Object value as EXOTIC-TARGET, set ERROR to 
"InvalidStateError", and terminate these steps.

Non-Normative Note: we can modify step 4 to support non-HTML elements in the 
future. In step 11, ELEMENT can be different from EXOTIC-TARGET if the custom 
element's constructor instantiates another instance of the same custom element 
before calling super().


== HTMLElement constructor ==

Non-Normative Note: HTMLElement's constructor is called via super() call inside 
the custom element constructor.

1. Let TARGET be GetNewTarget(). [4]
2. Let DOCUMENT be the associated document of the global object (the result of 
GetGlobalObject() [5]).
3. Let REGISTRY be the (custom element) registry of DOCUMENT.
4. Let DEFINITION be the element definition with the element interface, TARGET, 
in REGISTRY.
5. If there is no matching definition, throw TypeError and terminate these 
steps.
6. Let NAME be the local name of DEFINITION.
7. If the element construction stack of DEFINITION is empty,
   1. Return a new element that implements HTMLElement, with no attributes, 
namespace set to the HTML namespace,
  local name set to NAME, and node document set to DOCUMENT.
8. Otherwise, let INSTANCE be the last entry in the element construction stack 
(i.e. in LIFO).
9. If INSTANCE is a "AlreadyConstructed" marker, throw InvalidStateError and 
terminate these steps.
10. Otherwise, replace the last entry in the element construction stack with a 
"AlreadyConstructed" marker.
11. Return INSTANCE.

Non-Normative Note: step 7.1. is like step 4 in createElement [6] and happens 
when author script instantiates a custom element without going through DOM. 
e.g. "new X". Checks in Step 9 and 10 are needed when author scripts constructs 
invokes super() multiple times inside a custom element constructor. Step 9 is 
sufficient for the Custom Element Construction Algorithm to fail because it 
checks the exception in step 9. Step 5 could throw NotSupportedError instead if 
people would prefer that.


[1] https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md
[2] https://www.w3.org/2016/01/25-webapps-minutes.html
[3] 
http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-function-objects-construct-argumentslist-newtarget
[4] http://www.ecma-international.org/ecma-262/6.0/#sec-getnewtarget
[5] http://www.ecma-international.org/ecma-262/6.0/#sec-getglobalobject
[6] https://dom.spec.whatwg.org/#dom-document-createelement


- R. Niwa

Re: TPAC 2016 - meetings

[Ryosuke Niwa]

I'd like to attend Web Perf WG's meeting so it would be ideal if any meetings 
held for Web Apps WG didn't overlap with those of Web Perf WG's.

> On Feb 10, 2016, at 4:34 AM, Chaals McCathie Nevile  
> wrote:
> 
> Dear all,
> 
> as you probably know, the W3C will hold its Technical Plenary meeting this 
> year in Lisbon, September 19-23.
> 
> Rather than meet for several days in plenary, with an hour or two for any 
> given topic we are considering an approach that gives more focused time to a 
> few important areas of work.
> 
> We propose people ask for time to work on a particular area, for example "a 
> day for editing and UI events", or "2 hours for File APIs".
> 
> If there are other topics you don't want to clash with, e.g. because of 
> significant overlap, please say so.
> 
> We will have to reserve the physical spaces by the end of March, which means 
> while we might be able to shuffle individual meetings a bit, we need to know 
> pretty soon what sort of meetings we should be trying to accommodate.
> 
> We anticipate having a plenary session as some part of the final day, which 
> will mostly be a quick wrap on what happened for each group that met, and a 
> quick run-down of all the other work we have - much as webapps has 
> traditionally done at the *start* of its TPAC meetings in the past.
> 
> As well as feedback on what meetings you think you will need, we of course 
> appreciate feedback on the plan itself.
> 
> cheers
> 
> Chaals, for the chairs
> 
> -- 
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
> 

[custom-elements] Invoking lifecycle callbacks before invoking author scripts

[Ryosuke Niwa]

Hi,

We propose to change the lifecycle callback to be fired both before invoking 
author scripts (e.g. for dispatching events) and before returning to author 
scripts.

Without this change, event listeners that call custom elements' methods would 
end up seeing inconsistent states during compound DOM operation such as 
Range.extractContents and editing operations, and we would like to avoid that 
as much as possible.

- R. Niwa

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

I found a very interesting, and inspiring quote today that I'd like to
share with you: -

https://twitter.com/jaffathecake
Googler. "I want the web to do everything native can, and fast."

So  can anyone here explain to me how that precludes device/user tracking?
Or how HTML5 Web Apps can not be available today with the same
functionality as Uber, Domino's, GrindR, FaceBook, tomtom?

What the hell are you waiting for?

Here's a couple more platitudes to get you through to the next F2F plenary
junket: -

https://twitter.com/jaffathecake/status/633621917547778048

"The web should look to increase its advantages while reducing its
disadvantages. Native is doing this too. If the web stops, it dies."

"The web doesn't need to be better than native at everything, it just needs
to be close enough that the gap in certain areas doesn't matter."

Re: File API - where are the missing parts?

[Jonas Sicking]

On Sun, Feb 21, 2016 at 3:32 AM, Florian Bösch  wrote:

>
> *What this covers*
>
>- Read one or many files in their entirety in one go (in python that
>would be open('foobar').read())
>- Save a completed binary string in its entirety in one go to the
>download folder (no overwrite)
>- Listen to file modifications
>
> Is the last bullet here really accurate? How can you use existing APIs to
listen to file modifications?

There are also APIs implemented in several browsers for opening a whole
directory of files from a webpage. This has been possible for some time in
Chrome, and support was also recently added to Firefox and Edge. I'm not
sure how interoperable these APIs are across browsers though :(

I would also add that existing APIs does allow partial reads. You can slice
a blob to get a smaller blob, and then read that. Slicing is a cheap
operation and should not copy any data.

Using this you can actually emulate incremental reads, though it is not as
easy as full streaming reads, and it might have some slight performance
differences.



> *What is missing*
>
>- Read a file incrementally (and with the ability to abort)
>- Save a file incrementally (and with the ability to abort)
>- Overwrite a file (either previously saved or opened)
>- Save as pickable destination
>- Save many files to a user pickable folder
>- Working directory
>
> Another important missing capability is the ability to modify an existing
file. I.e. write 10 bytes in the middle of a 1GB file, without having to
re-write the whole 1GB to disk.

However, before getting into such details, it is very important when
discussing read/writing is to be precise about which files can be
read/written.

For example IndexedDB supports storing File (and Blob) objects inside
IndexedDB. You can even get something very similar to incremental
reads/writes by reading/writing slices.

Here's a couple of libraries which implement filesystem APIs, which support
incremental reading and writing, on top of IndexedDB:

https://github.com/filerjs/filer
https://github.com/ebidel/idb.filesystem.js

However, IndexedDB, and thus any libraries built on top of it, only
supports reading and writing files inside a origin-specific
browser-sandboxed directory.

This is also true for the the Filesystem API implemented in Google Chrome
APIs that you are linking to. And it applies to the Filesystem API proposal
at [1].

Writing files outside of any sandboxes requires not just an API
specification, but also some sane, user understandable UX.

So, to answer your questions, I would say:

The APIs that you are linking to does not in fact meet the use cases that
you are pointing to in your examples. Neither does [1], which is the
closest thing that we have to a successor.

The reason that no work has been done to meet the use cases that you are
referring to, is that so far no credible solutions have been proposed for
the UX problem. I.e. how do we make it clear to the user that they are
granting access to the webpage to overwrite the contents of a file.

[1] http://w3c.github.io/filesystem-api/

/ Jonas