[Bug 13913] Attributes don't have an order

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913
Bug 13913 depends on bug 17871, which changed state.

Bug 17871 Summary: Element attributes should not be required to be stored in an 
ordered list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17871

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [service worker] f2f meeting notes, next meeting details

[Ali Alabbas]

Hello, here are the day 2 meeting notes from the service worker F2F in 
Redmond,. The attendees are CC'd if there are any corrections that need to be 
made or if anyone has any questions or concerns that they would like to raise.

=

Service Worker F2F
Redmond, WA
April 12, 2016

Day 2 Notes

Attendees:
-
 * Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead, 
Todd Reifsteck
 * Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell, Marijn 
Kruisselbrink
 * Mozilla - Ehsan Akhgari, Ben Kelly, Andrew Sutherland (remote)
 * Samsung - Jungkee Song
 * Apple - Ted O'Connor


Agenda & Notes:
-
 * Foreign fetch architecture (#878: Foreign fetch vs non-credentialed requests)
  * Reduce state on the serial object
  * Is there a way to fetch something locally that will always be visible?
   * Yes, if there's no origin, it will be an opaque response
  * New CORS header that the destination needs to support?
   * alice.com (A) foreign fetch to bob.com (B), response from B to A: 
that's a cross-origin request
  * Want to reuse CORS infrastructure as much as possible
  * Must create a new Response with the CORS headers
  * SW is like B's server
  * Response always creates a copy of the response and then modifies it
  * Mechanisms should be the same in that the service worker
  * Should we loop the request back through CORS or should we just make it 
visible for the origin?
  * Adding a new step with what the service worker responds with (adding 
extra step in the network layer)
  * Current security model is that A can do whatever it wants to A
   * A has a security boundary (SOP) since it's in a different origin
  * Constraining foreign fetch would defeat the purpose
  * A can only see what credentials that are exposed through scripts (which 
are none today)
  * We shouldn't allow transparent smuggling of data
   * A requesting data from C is not allowed
   * A requests data from B which then requests from C and passes that 
data on will have the same headers as C unless B creates a new response with 
different headers
  * CORS does not fit model
  * Why make foreign fetch more complicated than postMessage in terms of 
how origin B lets origin A have access to bytes?
   * postMessage doesn't allow you to send opaque bytes
  * Response time is when the CORS check occurs
   * After the network request goes out is when the check occurs
  * B can do whatever it wants to B and expose it to A
  * We should minimize the number of policy security mechanisms so that we 
do not have to service different policies
  * A can make a request that initiates a foreign fetch even and 
intercepted by B's service worker without having known and potentially with 
no-credentials
  * We don't need preflight because it requires that you are going to the 
network and SWs don't necessarily require going to the network
  * Fonts and analytics are the biggest use case for foreign fetch at the 
moment
  * Opaque requests can allow no-credentialed request
   * It would create some issues with maintainability
   * Would prefer to have some sort of partitioning instead
  * New issue created: #878: Foreign fetch vs non-credentialed requests
   * Summary from issue: As currently specified foreign fetch doesn't 
play together well with non-credentialed requests. In a world without foreign 
fetch, a website on origin A can fetch something from origin B without 
credentials, and there is no way (modulo fingerprinting) for B to associate 
that request with its cookies. If B can intercept the request with foreign 
fetch this is no longer the case as B itself was fetched with credentials, and 
can make credentialed requests and access data that was cached using 
credentials. There are a few options here:
   * Live with this: non-credentialed requests aren't an important 
security/privacy boundary since B can use fingerprinting etc. anyway to track 
things and associate requests with credentials.
   * Completely disable foreign fetch interception of non-credentialed 
requests. This would be very unfortunate as things like fonts are always 
fetched without credentials, so this would disable a major use case of foreign 
fetch.
   * Require origin A to opt in to having its non-credentialed requests 
be intercepted by a foreign fetch service worker. This would be rather 
unfortunate as well, as it would largely get rid of the transparent nature of 
foreign fetch, making it much less powerful.
   * Somehow make it possible for origin B to say "this service worker 
does not need credentials". In the case of something like the fonts use case 
this would be done by adding an extra flag to the Link: header that installs 
the foreign fetch 

Re: [service worker] f2f meeting notes, next meeting details

[Ali Alabbas]

Hello, here are the day 1 meeting notes from the service worker F2F. The 
attendees are CC'd if there are any corrections that need to be made or if 
anyone has any questions or concerns that they would like to raise.

=

Service Worker F2F
April 11, 2016


Attendees:
-
   * Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead
   * Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell, 
Marijn Kruisselbrink
   * Mozilla - Ehsan Akhgari, Ben Kelly
   * Samsung - Jungkee Song
   * Apple - Ted O'Connor


Agenda:
-
   * Vendor comments on general direction
   * v1 issues
 

Vendor comments on general direction (e.g. Tim’s comment)
-
   * Service workers are overly complicated for simple use cases
   * Ted O’Connor: don't worry about Tim's comment
   * Matt Falkenhagen: Average time for starting up SW when a fetch is 
registered is 150 ms
 

v1 Issues:
-
   * #861: be more explicit that jobs always run asynchronously
  * Already implemented this way in Gecko, but would be nice to have it be 
part of the spec
  * Spec originally allowed register to run sync, but need to be consistent
  * Don't want to spawn new jobs and have jobs running in parallel (we want 
to have one job queue)
  * Resolution: update spec language to ensure that all jobs are scheduled 
asynchronously
   * #850: FetchEvent.respondWith does something weird with the body of a 
response
  * Streams need to be figured out (pipeTo algorithm)
  * In the meantime, some steps have been put in place until everything is 
spec'd in Fetch
  * Consuming body input to the API so that scripts can't read after that
  * Comment from Yushino from Google who was working on Streams: pipeTo 
transfers the object via teeing
  * We probably don't want to tee because we want to consume data
  * Outcome: wait and see then change the spec with what is required to 
accommodate changes from Fetch API
   * #848: "Wait for all the tasks queued by Update State" language is 
problematic
   * #851: Install algorithm step 14 should clear waiting worker before 
updating state to redundant
   * #860: spec should queue tasks to expose attribute changes on ServiceWorker 
and ServiceWorkerRegistration
  * Queuing task per execution environment
  * Expectation is that the attributes are in a certain that state
  * There may always be a race between getters
  * Fully deterministic way for getters in this fashion is via event 
listeners
  * Bug in Gecko: registration.installing and activating currently returns 
null
  * Outcome: queue a task to update these values per context, when the 
state changes.
 * 
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#update-state-algorithm
 - this should queue a task to update the serviceWorker.state objects, and the 
registration.waiting (etc) objects.
 * In the updatefound listener, reg.installing should always be the new 
worker, even if there's no install event.
 * In the statechange listener, the registration should be updated.
   * #816: ExtendableMessageEvent.source cannot be SameObject
  * Outcome: update spec reflecting IDL changes
  * Related issue filed in IDL - no update now, will ping
   * #810: MessagePort[] no longer valid in WebIDL
  * Resolution: spec needs to be updated
   * #870: Inconsistencies due to when clients are created
  * When opening a new tab, Chrome (in initial fetch event) there will be a 
client there and in Mozilla there isn't
  * Potential client ID can be used to provide information about what the 
client is if it's not created yet
  * Want to have a rich Fetch event that can include if it was a soft/hard 
reload
  * Once it's in the history and doesn't show up in client lists, the 
document shouldn't exist anymore
  * No client is created for content-disposition downloads
 * This is a reason for just using potential client ID rather than 
re-using the client ID
  * What do you want to do with a client before it's created?
 * Developer may want to cater the content to fill in the client based 
on the window size
  * Do we create a client before the request goes through even if the 
client does not end up being used?
  * Don't update service worker if there is a reload of a page since there 
is no moment when the client is disengaged from being controlled by the service 
worker
  * For window.open, about:blank inherits the creator (i.e., it is 
controlled)
  * We are already committed to having a potential client if we have a 
potential client ID, so we should be able to introspect that client in the 
clients list
  * about:blank is the url of the reserved (potential) client
  * Resolution: have client ID and potential client ID, clients.matchAll 
will not return all 

Re: [Custom Elements] They are globals.

[/#!/JoePea]

On Mon, Apr 11, 2016 at 4:44 PM, Ryosuke Niwa  wrote:
> You'd have to instead write it as "new SomeClass(this.shadowRoot)" and then 
> (1) needs to be modified as: `super(..arguments)` to pass the argument along 
> to the HTMLElement constructor.

For sure, similar to the examples in the GitHub issue. :]

React doesn't encourage the instantiation of element classes directly.
What if browsers did that too and threw errors whenever someone tried
to instantiate a class using `new` that extended from any of the
native classes:

```js
import {SomeElement} from 'some-library'

// this would cause a `TypeError: Illegal constructor` or something
let el = new SomeElement()

// does not return a constructor
shadowRoot1.registerElement('any-name', SomeElement)

// only this instantiation method is allowed
let el1 = shadowRoot1.createElement('any-name')

// we can use the same class in a different component where
//  is already defined but isn't backed by SomeElement
shadowRoot2.registerElement('other-name', SomeElement)
let el2 = shadowRoot2.createElement('other-name')

// maybe this should throw an error instead of returning
// HTMLUnknownElement, otherwise it might hide the obvious
// human error instead teaching the developer
shadowRoot1.registerElement('a-name', SomeElement)
let el3 = shadowRoot2.createElement('a-name')

// this would cause an error because el1 was created from
// shadowRoot1 so el1 doesn't work in shadowRoot2
shadowRoot2.appendChild(el1)
```

ShadowDOM is still evolving and the Web Component spec hasn't
officially settled, so I think there's a good opportunity here for the
web to be more helpful by throwing errors and not being ambiguous as
for example in `document.createElement('ths-has-a-typo')`.

TLDR - ShadowDOM could be the encapsulation of HTML to Custom Elements
as JSX is the encapsulation of HTML to React Components (in a morphed
way, as obviously the mechanics are different).

Here's what a small component might look like:

```js
//  --- HandyForm.js
import AwesomeButton from './AwesomeButton'
import { FancyForm, FancyInput } from './FancyForm'

export default
class HandyForm extends HTMLElement {
constructor() {
this.root = this.createShadowRoot()
this.root.registerElement('', AwesomeButton)
this.root.registerElement('', FancyForm)
this.root.registerElement('', FancyInput)

const frag = document.createDocumentFragment()
frag.innerHTML = `


 



`
this.root.appendChild(frag)
}

static get observedAttributes() { return [ ... ] }

connectedCallback() { ... }
disconnectedCallback() { ... }
attributeChangedCallback() { ... }
}

//  --- app.js
import HandyForm from './HandyForm'

// elements registered on the document won't cross into shadow roots
document.registerElement('handy-form', HandyForm)
document.body.appendChild(document.createElement('handy-form'))
```

- Joe

/#!/JoePea

[Bug 24732] Remove DOMError from FileAPI

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@aryeh.name
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.