[Bug 27511] New: [Shadow]: Six node trees in the diagram but description says "seven"

[bugzilla]

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

Bug ID: 27511
   Summary: [Shadow]: Six node trees in the diagram but
description says "seven"
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

"seven node trees" in shadow DOM spec 2.3.1.

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

RE: Help with WebIDL v1?

[Travis Leithead]

> From: Sam Ruby [mailto:ru...@intertwingly.net]
> 
> Another way to phrase this question: what would the CR exit criteria be for
> such a WebIDL v1?  The reason why I bring this up is that if they are too low
> to be meaningful, that brings into the question whether or not this exercise
> is meaningful.  Similarly, if they are too high to be likely to be met.

I think just having the syntax in v1 does not make progressing v1 a useful 
indeavor. My understanding of how V1 was being maintained up-to-date was that 
updates to the binding that were shared across common syntax in both v1 and v2 
were being back-ported to v1 so that there were no inconsistencies in binding. 
In other words, if you were looking at v1, you'd see the latest algorithms and 
bindings, but for areas of v2 that were wholly new concepts, those would not 
exist in v1. 

Based on what Boris has said, I'm guessing that this practice has been 
discontinued :(

I don't think we need to have a requirement of maintaining an "ES5-level" goal 
for v1. Large parts of ES6 are now shipping in various browsers, so we really 
have no reason to keep an ES5-based spec in development.

Coming back to CR exit criteria, I think we need to hold v1 to the same 
standard we're holding v2, which means [at least] porting back the updated 
algorithms for handling sequences, named properties, indexed properties, etc. 
which have diverged.

I suspect that there are still some shared areas of v2 and v1 that are not yet 
locked down yet, and we should focus our collective efforts on stabilizing 
those features before working on v2-only syntax features.

> If, on the other hand, there is a "sweet spot" some place in the middle; then
> perhaps this effort should proceed.

I'm not sure what a middle-ground would look like--perhaps a less-strenuous 
test suite? E.g., HTML's "passive-permissive" testing approach?

> By analogy, the parsing of http: absolute URLs is solid and unlikely to 
> change,
> but determining the origin of file: URLs isn't.  Clearly identifying what 
> parts
> are widely deployed and unlikely to change vs those that aren't may be a
> path forward.

And I think that v1 should be that slice of "widely deployed" and unlikely to 
change features. If that means pulling out sequence from v1, then perhaps 
that's another approach.

I'm of the view that we should publish something soon to enable the stable 
reference for a variety of specs. Publishing is a process that helps focus and 
direct our efforts, and even if it's not perfect, it becomes a building block 
for future updates. We've let WebIDL just "hang-out" for too long now, and 
folks new to the area don't know what's more stable and what isn't.

Again, publishing WebIDL is important to Microsoft, and we believe important to 
a lot of other customers. Consequently I'm ready to put pen to paper to make 
this happen if we can agree on a direction. Ideally, this effort doesn't 
distract too much from active work on v2.

> - Sam Ruby

Re: Help with WebIDL v1?

[Sam Ruby]

On 12/03/2014 11:10 AM, Boris Zbarsky wrote:

On 12/3/14, 6:02 AM, Yves Lafon wrote:

Pretty much like refactoring XHR using Fetch or not. Most
implementations will most probably move to the latest version, but the
external interface will be the same.


"External interface" being the IDL syntax in this case, not the
resulting web-exposed interface, right?


In the case of Sequence, the ES
binding says in the two versions "IDL sequence values are represented
by ECMAScript Array values."


That's only really true for sequence return values in v2.  sequence
arguments are represented by ES iterables.


The option 2 you outline seems best here, the syntax is considered as
stable (well, can be expanded, things can be declared obsolete, but
there won't be breaking changes), but implementations (as in the es
binding algorithms) may change to match the evolution of the underlying
language.


OK.  I can live with this as long as the people referencing v1 can live
with it.


Or another example: in v1 having an indexed getter implies nothing
about being iterable, but in v2 it implies ES6 iterability.


This is an example of v1 plus one feature.


Not plus an IDL feature.  As in, this is not a case of "v2 adds some IDL
syntax compared to v1, but if you never use it in your spec you never
have to worry about it".  This is a case of "the same syntax has
different resulting behavior in implementations depending on which
version of IDL they implement, leading to possible lack of interop for
different implementations of your spec depending on which IDL version
they choose to use".

This is why in option 2 it's important to spell out what the actual
requirements on implementations are that arise from the IDL reference.


Another option would be to define only the syntax and leave the bindings
to v2 only, but it wouldn't help much for testing.


Indeed.  Or, again, actual interop.


Another way to phrase this question: what would the CR exit criteria be 
for such a WebIDL v1?  The reason why I bring this up is that if they 
are too low to be meaningful, that brings into the question whether or 
not this exercise is meaningful.  Similarly, if they are too high to be 
likely to be met.


If, on the other hand, there is a "sweet spot" some place in the middle; 
then perhaps this effort should proceed.


By analogy, the parsing of http: absolute URLs is solid and unlikely to 
change, but determining the origin of file: URLs isn't.  Clearly 
identifying what parts are widely deployed and unlikely to change vs 
those that aren't may be a path forward.



-Boris


- Sam Ruby

Re: PSA: Publishing working draft of URL spec

[Sam Ruby]

On 12/03/2014 10:57 AM, Arthur Barstow wrote:

On 12/3/14 10:42 AM, Sam Ruby wrote:

On 12/02/2014 06:54 PM, cha...@yandex-team.ru wrote:

I'm new to being a W3C Editor, but I did manage to find:
http://www.w3.org/2005/07/pubrules


Besides the above, the following which includes links to the various
validators:

  
.


Thanks!


Updated draft:

https://rawgit.com/w3ctag/url/develop/url.html


Please run validator.w3.org/checklink and it appears you want to delete
the "...-1-..." in the "This version" link.


This is a consequence of the first issue I mentioned, namely that 
Bikeshed adds a level identifier to the URL:


http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0547.html

---

Running the WebIDL checker results in three errors being reported.

http://tinyurl.com/kcwx2hj

Can somebody confirm that these are real errors?


-Thanks, AB


- Sam Ruby

Re: Help with WebIDL v1?

[Boris Zbarsky]

On 12/3/14, 6:02 AM, Yves Lafon wrote:

Pretty much like refactoring XHR using Fetch or not. Most
implementations will most probably move to the latest version, but the
external interface will be the same.


"External interface" being the IDL syntax in this case, not the 
resulting web-exposed interface, right?



In the case of Sequence, the ES
binding says in the two versions "IDL sequence values are represented
by ECMAScript Array values."


That's only really true for sequence return values in v2.  sequence 
arguments are represented by ES iterables.



The option 2 you outline seems best here, the syntax is considered as
stable (well, can be expanded, things can be declared obsolete, but
there won't be breaking changes), but implementations (as in the es
binding algorithms) may change to match the evolution of the underlying
language.


OK.  I can live with this as long as the people referencing v1 can live 
with it.



Or another example: in v1 having an indexed getter implies nothing
about being iterable, but in v2 it implies ES6 iterability.


This is an example of v1 plus one feature.


Not plus an IDL feature.  As in, this is not a case of "v2 adds some IDL 
syntax compared to v1, but if you never use it in your spec you never 
have to worry about it".  This is a case of "the same syntax has 
different resulting behavior in implementations depending on which 
version of IDL they implement, leading to possible lack of interop for 
different implementations of your spec depending on which IDL version 
they choose to use".


This is why in option 2 it's important to spell out what the actual 
requirements on implementations are that arise from the IDL reference.



Another option would be to define only the syntax and leave the bindings
to v2 only, but it wouldn't help much for testing.


Indeed.  Or, again, actual interop.

-Boris

Re: PSA: Publishing working draft of URL spec

[Arthur Barstow]

On 12/3/14 10:42 AM, Sam Ruby wrote:

On 12/02/2014 06:54 PM, cha...@yandex-team.ru wrote:

I'm new to being a W3C Editor, but I did manage to find: 
http://www.w3.org/2005/07/pubrules


Besides the above, the following which includes links to the various 
validators:


 
.



Updated draft:

https://rawgit.com/w3ctag/url/develop/url.html


Please run validator.w3.org/checklink and it appears you want to delete 
the "...-1-..." in the "This version" link.


-Thanks, AB

Re: PSA: Publishing working draft of URL spec

[Sam Ruby]

On 12/02/2014 06:54 PM, cha...@yandex-team.ru wrote:


If the document doesn't meet "pubrules", that will cause a delay as
Sam and I deal with it.


I'm new to being a W3C Editor, but I did manage to find: 
http://www.w3.org/2005/07/pubrules


I made a number of fixes:

https://github.com/whatwg/url/commit/0b3840580f92a7d15a76235d8ee67254ca0824da

https://github.com/w3ctag/url/commit/1ea9cc3ac4594daa670864d1568832251199dfa7

Updated draft:

https://rawgit.com/w3ctag/url/develop/url.html

Pubrules results:

http://tinyurl.com/lphqp9b

---

Open issues:

1) The title page date and the date at the end of the "This Version" URI 
MUST match.


Issue: Bikeshed adds a level identifier to the URI[sic].

Options: request a variance; patch bikeshed; have the webmaster fix this 
downstream.


2) The editors'/authors' names MUST be listed.

Issue: one of the editors is not a WG member, both editors prefer 
editors NOT be listed.  This is not unique:


http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0105.html

Recommendation: request a variance.

3) The copyright MUST use the following markup

Issue: the pubrules mandated markup doesn't match the charter specified 
license for this specification.


Recommendation: request a variance.

4) All proposed XML namespaces created by the publication of the 
document MUST follow URIs for W3C Namespaces.


Issue: the pubrules checker seems to have found an XML namespace where 
none is present nor intended.


Recommendation: request a variance.


There is an open CfC to move the document to the 2014 Process, but it
doesn't really matter whether this or the next Public Working Draft
is published under that process so it won't hold up a Public Working
Draft if we can get the pubrules etc sorted in time.


I've left the 2005 process link for now; will update once the CfC completes.


cheers

Chaals

-- Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com


- Sam Ruby

Re: Help with WebIDL v1?

[Anne van Kesteren]

On Wed, Dec 3, 2014 at 3:02 PM, Yves Lafon  wrote:
> Another option would be to define only the syntax and leave the bindings to
> v2 only, but it wouldn't help much for testing.

Well we don't want to test something known to be wrong (e.g.
sequence). And we want to retain the ability to make changes to the
IDL syntax as we discover problems with it.


-- 
https://annevankesteren.nl/

Re: Help with WebIDL v1?

[Yves Lafon]

On Mon, 1 Dec 2014, Boris Zbarsky wrote:


On 12/1/14, 1:49 PM, Travis Leithead wrote:
I believe so; this will give many specs a baseline WebIDL document to point 
to in their references at the very least. Many specs don't rely on the more 
advanced feature set being defined in WebIDL Second Edition.


Here's the problem.

As of today, v2 is not just v1 plus some more features.  They actually have 
some disagreements on how identical IDL syntactic constructs are handled. 
For example, sequence behavior is different: in v1 a sequence has magic for 
platform array objects and the gets the "length" property and goes from 0 to 
length, while in v2 a sequence is an iterable and uses the ES6 iterator 
protocol.


Pretty much like refactoring XHR using Fetch or not. Most implementations 
will most probably move to the latest version, but the external interface 
will be the same. In the case of Sequence, the ES binding says in the two 
versions "IDL sequence values are represented by ECMAScript Array 
values."


The option 2 you outline seems best here, the syntax is considered as 
stable (well, can be expanded, things can be declared obsolete, but there 
won't be breaking changes), but implementations (as in the es binding 
algorithms) may change to match the evolution of the underlying language.


Or another example: in v1 having an indexed getter implies nothing about 
being iterable, but in v2 it implies ES6 iterability.


This is an example of v1 plus one feature.

More generally, v1 is pretty much defined in ES5 terms, while v2 is aiming 
for closer convergence with ES6.


What happens when a spec uses a sequence argument and references v1? Are UAs 
supposed to implement the v1 behavior or v2 behavior?


However, let's not hijack this thread; I'd love to hear what the next steps 
are for moving this v1 forward.


I think that actually depends on how we want to handle the problem I describe 
above.


Some obvious options are:

1)  Backport all behavior changes from v2 to v1 so they agree on the set of 
syntactic constructs supported by v1.  This makes v1 depend on ES6, which I 
understood to be a non-goal (or perhaps even anti-goal, given ES6 is not 
finalized yet?  But it's close).


2)  Treat v1 as a syntax spec (with v2 a superset of the syntax) and 
explicitly say somewhere in v1 that v2 can redefine the behavior.  Not sure 
how happy people referencing v1 will be with that.


Other options?


Another option would be to define only the syntax and leave the bindings 
to v2 only, but it wouldn't help much for testing.


--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

[Bug 27496] New: [Explainer]: mispell on inherifance

[bugzilla]

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

Bug ID: 27496
   Summary: [Explainer]: mispell on inherifance
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: sergiomc...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14949

"inherifance"
it's inheritance

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