Re: HTML editors meeting

[Ms2ger]

Hi Léonie,

Please don't send spam about your HTML fork to this mailing list; we were
promised the WG merge would not cause our time to be wasted with that crap.

Thanks
Ms2ger

On Tue, Mar 15, 2016 at 11:39 PM, Léonie Watson  wrote:

> Hello,
>
> There will be an HTML editors meeting on 10 - 11 May 2016, at Microsoft in
> Redmond. Info here:
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/10-11mayHTML.md
>
> If you are interested in joining the HTML editorial team, we would like to
> hear from you. Whilst anybody can submit a PR proposing a change to the
> HTML
> spec, the editorial team is responsible for reviewing PRs and merging them
> into the spec when they are ready.
>
> Léonie.
>
> --
> @LeonieWatson tink.uk Carpe diem.
>
>
>
>
>
>
>

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Art,

On 12/02/2015 02:23 PM, Arthur Barstow wrote:
> Yves and Travis would like to publish a Candidate Recommendation
> of WebIDL Level 1 and this is a Call for Consensus to do so. The
> draft CR is:
> 
> <https://ylafon.github.io/webidl/publications/cr-20151124.html>
> 
> If anyone has comments or concerns about this CfC, please reply by 
> December 9 at the latest. Silence will be considered as agreeing
> with the proposal and explicit responses are preferred. If no
> non-resolvable blocking issues are raised, this CfC will be
> considered as passing and we will proceed with a CR publication.
> 

I'd like to see the difference between this proposed CR and the latest
editor's draft.

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWXwo9AAoJEOXgvIL+s8n284QH/1Q1qBZW6Cg+HacdgWbCNhBj
tZJ4uRm+m3mTeTr21cXmh2J79lhqFHv8lkX/T+mpe9/B5Z8VHFbA/ZAxDRoQKV25
J4Wtx0lZtt90m0hP1gPG1jMYSIpy94RY+PGBnZ/tAa4IPjCGtuOhDRCdXL4VQ9gn
DzdV5wOkVCWmAZCbq39x3D+y8PfDMyd8p3qkB304y+wHkVhhNkn5/47mk18HP6C5
ry5ljb7iZz+d2QeJBeJd96S7QqbOJEOt7FaQR7oqkj/tScLs6atSZlKn2l3s0B1Q
GmoyKsZTSRU2NWwKDfDZ775fCBwGLqGYBpSzgrInuGYTZmDgu4GHsD9OxmPwXXM=
=rY+n
-END PGP SIGNATURE-

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Ms2ger]

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote:
> This is a call for comments regarding the next step of Web Workers.
> 
> The latest [TEST RESULTS] of Web Workers indicate that Dedicated
> Workers have been widely implemented by the major browser vendors.
> 
> [Diff] between the latest W3C WD and the WHATWG living standard
> suggests substantial changes about the WorkerLocation interface, and
> the test results of the [WorkerLocationTestCases] show that these
> changes have been adapted by more than two major browsers.
> 
> As for Shared workers, [TEST RESULTS] suggest that this feature is
> still poorly supported. Right now both Apple and Microsoft don’t
> intend to implement it, Chrome supports only a small part of it.
> There were issues raised about [Removing-Sharedworkers] on GitHub,
> one suggestion was to pull it out into a separate working note,
> whereas others thought it’s too early to do so.
> 
> Hence our questions to the group: Is the group still interested in
> moving Workers forward? Is it the right time to publish Workers as a
> CR? Should SharedWorkers be removed from this spec?
> 
> Please provide your thoughts on these questions by Dec 14 2015. If
> there’s no interest from the members to continue the work of
> WebWorkers in W3C, we will probably stop publishing new versions of
> this spec.
> 

Let's publish it as a REC; that no longer needs interop anyway (see:
DOM4 is a REC).

HTH
Ms2ger

Re: [Web Components] proposing a f2f...

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/28/2015 05:19 AM, Chaals McCathie Nevile wrote:
> it would be good to have a face to face meeting,

[citation needed]

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWMNsSAAoJEOXgvIL+s8n2c1YH/ji5YgPwZXMcIE2BDXpOfZ4G
USJwyL5EUwkPRO9iqZF4LthfgkvdDJ78VIQNAkDGtNfgnE1cAd1U2O+vDn5uq+20
nuaf5Vs/wOKxbnYW+S5rU0ajWVe3w2BWkKK+qCSqh3f9WlUbXoiW6L/zAfMGuREy
ido2hDEGQeN0UT5FXfNXiESCVuXajAFYIuguE3ML/aJ3rAIFNQs4DVKewAMwBQsG
NddB98MIZgMXo3lXBo6JOCLK//a66Rbk6SFRA16CTsM4h7s6GS5vu4ChqeBGOKOH
7qIhCBTu6af8rZ/xsDmxVuS/sv1J65yLS4bwkh8W2A0fe65vO5lqMsMvVrrpBwM=
=5DBN
-END PGP SIGNATURE-

Re: [XHR] Error type when setting request headers.

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Yves,

On 09/29/2015 03:25 PM, Yves Lafon wrote:
> Hi, In XHR [1], setRequestHeader is defined by this: [[ void
> setRequestHeader(ByteString name, ByteString value); ]] It has a
> note: [[ Throws a SyntaxError exception if name is not a header
> name or if value is not a header value. ]]
> 
> In WebIDL [2], ByteString is defined by the algorithm [[ • Let x be
> ToString(V). • If the value of any element of x is greater than
> 255, then throw a TypeError. • Return an IDL ByteString value whose
> length is the length of x, and where the value of each element is
> the value of the corresponding element of x. ]] So what should be
> thrown when one does
> 
> var client = new XMLHttpRequest(); client.open('GET', '/glop'); 
> client.setRequestHeader('X-Test', '小');
> 
> TypeError per WebIDL or SyntaxError per XHR? I think it should be
> TypeError, and SyntaxError for code <256 that are not allowed, but
> implementations currently use SyntaxError only.
> 
> [1] https://xhr.spec.whatwg.org/ [2]
> https://heycam.github.io/webidl/#es-ByteString
> 

This is perfectly explicit from the WebIDL specification. It defines
that `setRequestHeader` is a JavaScript function that does argument
conversion and validation (using the quoted algorithm in this case),
and only after that succeeded, invokes the algorithm defined in the
relevant specification (in this case XHR).

This implies in particular that a TypeError will be thrown here.
Indeed, the Firefox Nightly I'm running right now implements this
behaviour.

HTH
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWCqLDAAoJEOXgvIL+s8n26GQH/RPt+Nxxnmg0BXfIOySWeunn
2FHMlGiydCT5eek7oLvMhH3o2wyfgExEJrQyc9/emR+08sAlBZRRf5XkS+s+A8gQ
XMcHhv054bJ5zd1EV6t2V6E01PSIgQ0dUp5XtKF8xJR/J6opUodvm25jPGvomg7H
W4KelDI7LleeIAgKP7TLzLSsSmGS4/3QkjmleEB04Tso81IR3nXmpU75fYcsoDDg
ODJaNAtzauE9cMX6lXf9aEV2bnPGlgy9Ke5/Q8xYdadqy0xD44NFSGJNdQGzL/7P
Iy5ImE6uipky/O8vUUMCG7jdMYOJRGv3TiGyEMijAEsJOjpoN9ay3xdo1SHXO0A=
=U0HA
-END PGP SIGNATURE-

Re: Normative references to Workers.

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:
> If it helps, I’d like to prepare a Workers draft to revise the 
> previous CR, and schedule the publication ASAP (hopefully 22 Sep). 
> The goal is to synchronise with the upstream, to document the
> changes since the previous CR and to identify the "at risk”
> features.
> 

Why? What are you trying to achieve that makes doing that a good use
of your time (and the time of everyone else in that toolchain)?

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV/9PeAAoJEOXgvIL+s8n2AokIAJH7kcGJmSrNKn/SyKBeNGPH
INFwRIw8vReupG7g5rrIc9fErpV/4r/15dcpz87Z7IRx1S+Ne/6IrGWLnJMx+Boc
x7mvGW7rPm2Jqnq9S6s8W2n+QpFa4Z+2haznH+p9divt79Y7fYIhtwrcNEYc6z6c
Hs7wcfWGrCd7DbpjjMS2RdKls0YEHOkfu6VIi9wqn+DpFLXOYVgSg8CbiDtaRJiy
Pnjh3GuAl8hizW30tCUFF+YlELxQmRL6ojWnSb6AcD//VB+dFS3Jtf8QFEeL934i
kDQjyR1TUFlz7t3Xa409D48qpyG7/5s580KX5gRq0mFU8IhtzP2BNKMLgfgqvyw=
=X2q+
-END PGP SIGNATURE-

Re: Tests for new shadow DOM API

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ryosuke,

On 09/03/2015 10:06 PM, Ryosuke Niwa wrote:
> Hi all,
> 
> Where should we put tests for new shadow DOM API?  It looks like
> the tests in 
> https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shado
w-trees
>
> 
<https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shadow
- -trees>
> are mostly obsolete and I'm not certain how many of them could be 
> adopted for the new API.
> 
> Would it make sense to rename this old one to
> "deprecated-shadow-don" and then create a new top-level directory
> "shadow-dom"?  We can then migrate or write new tests there.
> 

If you believe a significant fraction of the existing tests is out of
date with the specification, I'd suggest moving them all into
`shadow-dom/untriaged` and adding a `README` file there to explain the
situation.

HTH
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV6VK2AAoJEOXgvIL+s8n2asAIAJEXWz8vyAGqPI6BFNNYQYXb
4i/knAt1/GEeiUOzjzbwJG38NRtGr9cZO0MCYW8S13gzzqKbtdCWwF0FbBvzvMR1
OHqkdR7tLo/aLV00GQzrLSgNDnqQ2M1+P/lq5QUU53DsbpTM2Ih0P1pjDsvaLs75
TZFggKN8UKhvjQrKuL1wjtCSKrdkemXKbdl2FfWgXj1hsUklNwKSmTd8Hr+g6FaS
eK+l74G7xhxbqwKvIo8MgcLjwNYJG5hPJWoP6T9b9rBnE4W+x8J9ojcVVMuCWz/4
0GOGvgyRXwobDcKsAcBomNhTruOC8pqNVn6e84oScOyNf8QRP6GDjyj/a2jd71I=
=Z5oS
-END PGP SIGNATURE-

Re: PSA: publish WD of "WebIDL Level 1"

[Ms2ger]

Hi Yves,

On 09/01/2015 11:30 AM, Yves Lafon wrote:
> On 31 Aug 2015, at 20:12, Ms2ger  wrote:
>> On 08/31/2015 03:28 PM, Yves Lafon wrote:
>>> In fact, I would prefer to have the editors’ copy published as 
>>> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version
>>> (aka, what is implemented, not what has to be implemented).
>>> 
>> 
>> Who do you propose will construct such a "what is implemented" 
>> specification, and what useful work would you have them drop for
>> it?
>> 
>
> Well, we need tests, of course. There is a test suite that needs to
> be checked again, and lots of other specs have tests that actually
> test parts of WebIDL. So apart from new functionalities that don’t
> have test yet (and may by mean of other specs testing those), most of
> the work is to gather existing tests, and I am ready to help on that.
> So I don’t ask anyone to stop doing their usual job, especially as it
> can also help here. Of course people reviewing tests is always a nice
> feature, as you know.
>

I'm not sure I understand your point. Tests will need to be written and
reviewed, whether "what is implemented" specifications are published or
not. My question is specifically about the editing of the documents you
propose to publish as -1 -2 … -n.

Thanks
Ms2ger

Re: PSA: publish WD of "WebIDL Level 1"

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Yves,

On 08/31/2015 03:28 PM, Yves Lafon wrote:
> In fact, I would prefer to have the editors’ copy published as 
> TR/WebIDL/, and let -1 -2 … -n be pointers to the stable version 
> (aka, what is implemented, not what has to be implemented).
> 

Who do you propose will construct such a "what is implemented"
specification, and what useful work would you have them drop for it?

Thanks
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV5JkbAAoJEOXgvIL+s8n27aQH/jCaZRS6ONmC1aklZACK5Iep
NV5VSxq1H2aHv6rdRiBNygeGzEiwENZUnIzv0r0ebQMCRCvhwXqbm+srV9FlFNdb
dJ7c41cXNHIk4D1+18vYvK4AenqkHE5zozm4LqoZ8SL+YLRFYyIhpXOsV34R5DnP
wjyLcEbcFgWmYK2TXTNphhTXEmebM89o4vmGkrKPdYqAwWaWNJz5L6hMZARH7lWq
eYL0iwo9BQbIfR0gLIpuARvS2oOS0Y7/8gNkMuEQ4h9UHa+hcvsOL0JWI6Zz2vTM
ZNO3nAE1h5In6DFXmK3ZkIlOpIGgsVsK7KmiIKlvZAOZ9NXui851uYA9j2YQQ3U=
=ixCO
-END PGP SIGNATURE-

Re: [Bug 27709] New: Dictionary MouseEventInit uses keyword attribute for its members

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/13/2015 06:26 PM, Vincent Scheib wrote:
> I could use more information here. 
> http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent
> specifies MouseEvent attributes with the attribute keyword. WebIDL
> description of attribute seems to apply here
> http://www.w3.org/TR/WebIDL/#idl-attributes. Why shouldn't the
> attribute keyword be used?

Answered in the bug.

Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJUtVfpAAoJEOXgvIL+s8n2wQ8H/R08N6E9k1+mxoCrHbt5SfRG
qJhm1e25I9wjsrSW/2fEdsOzaf3ydc6jFJiL6Z8deD1+88wAvFnOuvWh2pSeVJt4
q+ko12Uml6E8oSKMMT2serEodYpQRIhi+r6hQMeDwFIUPSMC+kJE34j4KYeOtiEz
A8P4wI5UiCIX/cyIzMXnVV0L0ZsET+4mKK+ciUXuSMohGQXGktztpdKlLBdBeSlc
yQ0ZZYC+eICxLOlpkWa94uiq8Hw72YupByAqf5fo2ItcV7+UfDVtJUlfe5nw1fMc
IuKeC7Y0Z+1bar7rRGHfJ3sCZACadGFLOOhraQfXnOHMmgmEpRY8ScJE3WEeP5Y=
=Ic2+
-END PGP SIGNATURE-

Re: [Custom] Custom elements and ARIA

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/28/2014 01:42 AM, Domenic Denicola wrote:
> TL;DR: we (Google) are trying to explain the platform with custom
> elements

[citation needed] on "explain the platform".

- -- 
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJT/tPwAAoJEOXgvIL+s8n2ceQH/iEtAZLBRca5CycU6WpHNX6s
CbNJbull0j9iV7XCdVwCraVzlSc7uDDmBEogJhWCxDd7L87BmfcLBNi864VvaFg1
NeYRzgeVqhsuMxeMXSMPYjmt0c1q3yqU9/yVFoBYx0IYZiqTZ63WCgMMN0zY8qmY
Skm0Bous9LaION4qs7JcYnYWe67oo52IPiOdN5qb/5mdE1D2IFXM9h6Mj38rR3eO
uQC6CZMe0KuW5pOADr+sIWb24+I+JWulZ3nacPnEVxL4VcXorxh5igUW44tzul7Z
kan2OyuubdxUlfFH0aL1X3sLNLE40/z+Cm18JdgabeWbrhbGHiCbTFNBHudCF4k=
=gzfC
-END PGP SIGNATURE-

Re: gamepad

[Ms2ger]

Hi Mark,

On 04/25/2014 10:13 PM, Mark Dodsworth wrote:

Hi,

Can I put forward that the sooner that web browsers can control gamepads
then the sooner the browser can become a true gaming platform. Please make
this a priority to make this a web standard, Thank you.



Firefox supports this, and this Working Group has published a 
specification [1] for it.


HTH
Ms2ger

[1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html

[pointerlock] Various comments

[Ms2ger]

Hi Vincent,

I have by no means reviewed the entire spec, but while reviewing the 
test cases, I noticed some room for improvement. Comments below.



In the "4. pointerlockchange and pointerlockerror Events" section [1]:

> "… with its |bubble| attribute set …"

should be |bubbles|. Probably best to link to the definition in DOM, too.


If you add attributes to MouseEvent, you should also add them to the 
MouseEventInit dictionary, so they can be initialized.



Defaults should be defined for those attributes in prose too, for the 
createEvent case. Text could be:


# When an event is created, the attribute must be initialized to […].


In the definition of requestPointerLock [2], a reference to DOM 3 Core 
is made; it looks like it should be to DOM 3 Events or UI Events instead.



In section "6.1 Attributes", the writable attributes have two 
consecutive commas in their definition:


> onpointerlockchange of type EventHandler, , nullable

Possibly a ReSpec bug; if so, please report to whereever such issues 
should be reported.



In general, the prose could be made less ambiguous. For example, the 
definition of exitPointerLock:


# Initiates an exit from pointer lock state if currently locked to a
# target in this document, and sends a pointerlockchange event when the
# lock state has been exited.
#
# The system mouse cursor must be displayed again and positioned at the
# same location that it was when pointer lock was entered (the same
# location that is reported in screenX/Y when the pointer is locked).

could be rewritten as:

| 1. If the pointer is not currently locked to a target in the
|context object, terminate these steps.
| 2. Exit the lock state. [Or should this be queued too? An
|unambiguous specification would have answered this
|question.]
| 3. Display the system mouse cursor again, positioned at the
|same location that it was when pointer lock was entered.
| 4. Deliver [link to section 4. pointerlockchange and
|pointerlockerror Events] a |pointerlockchange| event to the
|context object.
|Note: this is the same location that is reported in
|screenX/Y when the pointer is locked.


The dfn-exitpointerlock id is on an empty dfn element, which seems 
pretty silly.


HTH
Ms2ger

[1] 
https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#pointerlockchange-and-pointerlockerror-events
[2] 
https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#widl-Element-requestPointerLock-void

Re: [testing] Common way to "manage" test bugs?

[Ms2ger]

[ Bcc: public-webapps, public-webapps-testsuite ]

Hi Art,

On 12/19/2013 03:54 PM, Arthur Barstow wrote:

I think it would be helpful if WebApps had a common way to "manage" test
case bugs,  in particular:

1. A common way to report a test bug

2. An easy way to determine if a specific test suite has any open bugs.
(For example, if someone goes to the websockets test suite on WPT, it
should be easy to determine if any of the test cases have open bugs.)

>

Comments, proposals, etc. are welcome.


I strongly believe we should decide on a single way of managing bugs for 
all test suites in w-p-t (so moving the discussion to 
public-test-infra). It doesn't really matter to me whether that's done 
through github or bugzilla. Two things to consider, though:


* Some issues might span multiple test suites.
* It seems possible that we'd want to cross-reference test suite issues 
and specification issues.

* Cross-referencing commits/PRs with issues might also be useful.

HTH
Ms2ger

Objection to publishing DOM Parsing and Serialization (was Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3)

[Ms2ger]

Hi Art, all,

On 11/26/2013 08:43 PM, Arthur Barstow wrote:

Earlier today Travis closed the last open bug for DOM Parsing and
Serialization so this is a Call for Consensus (CfC) to publish a LCWD of
that spec, using the following ED as the basis:

   <https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html>

If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by December 3 at the latest. Positive response is
preferred and encouraged and silence will be considered as agreement
with the proposal.


(My apology for responding late, a single week is a rather short time 
for those of us who are not paid for this work.)


In the first place I'd like to note that I'm unhappy with the way this 
specification is being edited. The way it is explicitly trying to 
contradict the DOM standard is uncannily similar to the way DOM 3 Events 
did that (which, as you may remember, led to the WG deciding against 
those requirements). I don't think this specification has received 
sufficient review to call it LC-ready, especially given that there has 
not been any discussion of the changes before this CfC.


I also wish to strongly object to the following change:

https://dvcs.w3.org/hg/innerhtml/rev/8f29e6f6eea2

which you made after the end of the CfC. I don't think it is appropriate 
to make such a change without requesting review. The change to the list 
of editors reverts bug 18935 [1], and incorrectly suggests that I am 
involved with this fork. Even worse is the removal of the reference to 
the source specification, given that you know that this is a contentious 
subject in this WG.


I therefore object to the publication of this specification in the 
current form.


Ms2ger

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18935

Re: LINK only in HEAD?

[Ms2ger]

On 11/27/2013 08:44 PM, Dimitri Glazkov wrote:

On Wed, Nov 27, 2013 at 11:35 AM, Steve Souders  wrote:









Is the intention of this example that me-first and me-third occur in the
HEAD?



Sure. Nothing precludes the author from using custom elements in HEAD.


Except the HTML parser. Unknown elements imply . Feel free 
to use the Live DOM Viewer to confirm that.


HTH
Ms2ger

[1] http://software.hixie.ch/utilities/js/live-dom-viewer/

Re: RfC: LCWD of API for Media Resources 1.0; deadline June 3

[Ms2ger]

On 04/11/2013 07:00 PM, Anne van Kesteren wrote:

On Thu, Apr 11, 2013 at 5:21 PM, Arthur Barstow  wrote:

The Media Annotations WG decided to return its "API for Media Resources 1.0"
spec to LCWD and they have explicitly asked WebApps to review the new LC:

   <http://www.w3.org/TR/2013/WD-mediaont-api-1.0-20130411/>


1) As far as I can tell this an API for extracting EXIF data and such.

2) From the JavaScript examples it looks like the API is pretty horrible.

I'm wondering if there's a) implementors that have been following this
at all and b) where the other proposals are at. I'm pretty sure I've
seen some much simpler API ideas come by. I wonder what happened to
those.


For reference: 
<http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jun/0111.html>.


HTH
Ms2ger

Re: [editing] Is this the right list to discuss editing?

[Ms2ger]

On 02/19/2013 10:17 AM, Robin Berjon wrote:

On 19/02/2013 05:56 , Travis Leithead wrote:

Alex, work on Editing APIs was ongoing in the Community Group
(http://www.w3.org/community/editing/) though their draft is just under
a year old.


My recall is a bit rusty on that one, but I think that the situation was
that:

• WebApps is not chartered to publish this, so a CG was created.

• But having the discussion on the CG list seemed like a bad idea since
everyone is here, so the mailing list for discussion was decided to be
public-webapps.

I actually pinged Aryeh about this a week or two ago, but I haven't
heard back. I'd be happy to take over as editor for this spec, it's a
feature I've wanted to have work right forever.


FWIW, Aryeh is currently studying full time and doesn't follow web 
standards discussions regularly.



In order to make that happen (assuming that Aryeh agrees, or doesn't
speak up), I propose the following:

• Since I'm financed to work on HTML, transition this to an HTML
extension spec (this probably only requires a few changes to the header).

• The discussion can stay here (wherever people prefer that I'm already
subscribed to — I really don't care).

• The spec gets published through the HTML WG, since I believe it's
actually viably in scope there already.

All of the above assumes you're all happy with it, and the HTML people
too. I reckon it could work though.



Of course, I object to publishing this freely licensed specification in 
a working group that will insist on imposing a more restrictive 
copyright on it.


HTH
Ms2ger

[IndexedDB] Type of IDBCursor.source

[Ms2ger]

Hi,

IDBCursor.source is described as returning "object". It would be better 
to return the union (IDBObjectStore or IDBIndex), to make it clear that 
that is what's intended.


HTH
Ms2ger

[IndexedDB] Type of IDBRequest.readyState

[Ms2ger]

Hi,

The specification has the following IDL:

interface IDBRequest : EventTarget {
// …
readonly attribute enum   readyState;
// …
};

However, "enum" is not a type. The correct syntax would be something like

enum IDBReadyState { "pending", "done" };

interface IDBRequest : EventTarget {
// …
readonly attribute IDBReadyState  readyState;
// …
};

HTH
Ms2ger

[IndexedDB] Type of IDBRequest.source

[Ms2ger]

Hi,

IDBRequest.source has type "object" in the IDL snippet, but the 
definition claims the attribute can return null. If this is the case, 
the type should be "object?", as for all nullable types.


HTH
Ms2ger

[IndexedDB] Event handlers

[Ms2ger]

Hi,

The IDB specification still uses IDL like

  [TreatNonCallableAsNull] attribute Function? onsuccess;

for its event handlers. Current practice is to use

  attribute EventHandler onsuccess;

Please update the specification.

Thanks,
Ms2ger

[IndexedDB] IDBKeyRange should have static functions

[Ms2ger]

Hi all,

From the examples in the IDB specification (in [1], for example) and 
from existing implementations, it appears that the functions on the 
IDBKeyRange interface (only, lowerBound, upperBound and bound) should be 
static. However, there is no actual normative requirement to that 
effect; instead, the IDL snippet requires those functions to only be 
callable on IDBKeyRange instances. [2]


If this is caused by a bug in ReSpec, I suggest that either ReSpec is 
fixed or the spec moves away from ReSpec to a tool that doesn't limit 
what can be specified. In any case, an insufficient tool can not be used 
as an excuse for an incorrect specification, and I doubt we could 
publish a Rec without this shortcoming being addressed.


HTH
Ms2ger

[1] 
https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#key-generator-concept
[2] 
https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#idl-def-IDBKeyRange

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 12/03/2012 01:44 PM, Charles McCathie Nevile wrote:

Just a reminder: this group is a forum for discussion of technical
specifications, and follows the existing W3C process. Discussion of what
process *should* be is off topic here.


I find it unfortunate that you try to cut off discussions relevant to 
technical issues with our specifications by calling them "process" 
discussions.



 From my understanding reasons for the practice include the following:
  - W3C aims to provide stable specifications that can be used as
references which won't change. This is a general underpinning of its
policy for specifications published as "TR" documents. Making a
normative reference to an unstable document obviously defeats this purpose.


The argument that "TR" documents are in some way more "stable" than 
other documents is simply fallacious. This has been discussed at length 
here and in other venues; I won't go into it again.


Furthermore, I should point out that referencing the TR draft of WebIDL 
would (if anybody tried to implement the TR spec and its TR references; 
nobody does, of course) lead to a specification that is not 
implementable. The WebIDL used in XHR is not valid according to the 19 
April 2012 CR of WebIDL.



  - A couple of years ago, W3C was granted PAS submission status, after
applying for this at the urging of many of its members and of non-member
consumers of its specifications. This relies on lots of things, but one
of them is a certain clarity of process. ISO accepted W3C's process. I
don't know if they would be prepared to accept that of the WHAT-WG. I
don't even know anyone who cares enough to find out. In the meantime, I
suspect this is another reason not to make normative references to the
WHAT-WG's work and in particular to unstable documents.


I do not see how this is relevant; I though the process was clear, and 
that it did not censor references to particular organizations.



That's not in the W3C pub rules or a good idea.


It isn't written there, although it has been applied for as long as I
can remember (which stretches back to before "pubrules" was a document).


I would love to hear examples of where such a rule was applied before 
the W3C started co-publishing WHATWG specifications; in particular, 
cases where the W3C publication was significantly out-of-date in 
comparison to the alternative.



To the extent W3C thinks this should apply, they should indeed write it
in there, since it has recently become contentious.


As long as the rule doesn't exist, one can hardly expect editors to 
comply with it. If we expect editors to simply "do as we did before", 
we'd be stuck with DOM2-style specifications; I think we all agree that 
would not be good for interoperability.



Pubrules doesn't, as far as I know, prohibit "f-bombs" in specs. W3C
working group members, including editors, are expected to be socially
competent adults, which is a catch-all for what would otherwise be an
endless set of statements like "people who know not to use the 'f word'
in a spec even without a written rule". (If I recall correctly this is
in section 3.1 of the process document. It certainly isn't worth looking
up).


I find this comparison, in particular, to be unhelpful and rather rude. 
Nobody is suggesting using expletives in specifications. The only 
parallel I can imagine with the current situation is that some people 
seem offended by the existence of the WHATWG, and for some reason want 
to make sure no W3C publication ever mentions it. I had hoped we had 
been able to come to a somewhat more mature relationship between this WG 
and the WHATWG after the recent discussions about attribution, but 
changes like this make me lose confidence in the goals of the W3C Team 
and the chairs of this WG on this matter.


I maintain my technical objections to the publication.

HTH
Ms2ger

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 12/02/2012 01:38 PM, Arthur Barstow wrote:

On 12/1/12 3:34 PM, ext Ms2ger wrote:

I object to this publication because of this change:

http://dvcs.w3.org/hg/xhr/rev/2341e31323a4


For a couple of years now, if a spec proposed for publication in TR
includes a normative reference that hahas published as a TR, PLH has
insisted the reference needs to be a W3C document (TR or ED). (I'm
pretty sure a small number of references to non W3C documents slipped
through but I consider those mistakes.)

I asked Jungkee to make the reference changes to the TR versions so
thanks  Jungkee for the patch.

It would be OK with me if the references were changed to W3C EDs. Would
that take care of your objection?


No. I'd love to hear from plh why he would not leave decisions like 
these to the WG.


Ms2ger

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 12/02/2012 12:07 PM, Jungkee Song wrote:

On Sun, Dec 2, 2012 at 11:07 AM, James Robinson  wrote:


Sure there is if the W3C version is stale, as is the case here.


I don't think it's a technical issue to discuss. There should be
corresponding publication rules.

Art, Charles, Doug,
Can you help clarifying which links we have to use?

In the proposed version, I've changed the links to the following specs:
- [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest
W3C TR doc.
- [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the
latest W3C TR doc.


Please revert all those changes.

Thank you
Ms2ger

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 11/27/2012 02:16 PM, Arthur Barstow wrote:

On 11/27/12 12:21 AM, ext Jungkee Song wrote:

From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, November 27, 2012 3:05 AM

I think the next step is for the XHR Editors to create a TR version
using the WD template so that everyone can see exactly what is being
proposed for publication as a TR. Please create that version as soon as
you can so that this CfC can be based on that version (rather than the
ED) and reply with the URL of the TR version.

(Please use 6 December 2012 as the publication date.)

We prepared a proposed TR version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html


Thanks Jungkee.

All - <http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html> is the
document proposed for publication as a TR and thus is the basis for this
CfC.


I object to this publication because of this change:

http://dvcs.w3.org/hg/xhr/rev/2341e31323a4

pushed with a misleading commit message.

Thanks
Ms2ger

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 11/26/2012 02:44 PM, Jungkee Song wrote:

From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Monday, November 26, 2012 9:46 PM

On 11/26/12 1:38 AM, ext Jungkee Song wrote:

I suggest we put the following wordings for Anne's work and WHATWG to be

credited. If we make consensus, let me use this content for publishing the
WD.

Please put your proposed text in a version of the spec we can review and
send us the URL of that version.


Please find the version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html


Thanks, this looks a lot better. However, I'd also like to see a link to 
the source in the dl in the header.


Thanks
Ms2ger

Re: CfC: publish WD of DOM; deadline December 2

[Ms2ger]

On 11/25/2012 02:49 PM, Arthur Barstow wrote:

This is Call for Consensus to publish a  Working Draft of the DOM spec
using #ED as the basis.

Please note Lachlan will continue to edit the ED during this CfC period.

Agreement to this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support of the contents of the WD.

If you have any comments or concerns about this proposal, please reply
to this e-mail by December 2 at the latest.

Positive response to this CfC is preferred and encouraged and silence
will be assumed to mean agreement with the proposal.


*sigh*

Same objections as to the XHR WD.

Ms2ger

Re: CfC: publish WD of XHR; deadline November 29

[Ms2ger]

On 11/22/2012 02:01 PM, Arthur Barstow wrote:

TheXHR Editors  would  like to publish a new WD of XHR and this is a
Call for  Consensus to do so using the following ED (not yet using the
WD template) as the basis
<http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html>.

Agreement to this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate support of the contents of the WD.

If you have any comments or concerns about this proposal, please reply
to this e-mail by December 29 at the latest.

Positive response to this CfC is preferred and encouraged and silence
will be assumed to mean agreement with the proposal.


I object unless the draft contains a clear pointer to the canonical spec 
on whatwg.org.


Ms2ger

Re: Call for Consensus: CORS to Candidate Recommendation

[Ms2ger]

I object to making such a change.

On 11/16/2012 02:32 PM, Glenn Adams wrote:

Before going to CR, I believe the [HTML] entry in the references section
needs to be changed to reference an appropriate W3C specification. A
present, it reference a non-W3C document.

On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow wrote:


On 11/15/12 5:31 PM, ext Hill, Brad wrote:



I have placed a draft for review at:

http://www.w3.org/2011/**webappsec/cors-draft/

And this is a Call for Consensus among the WebAppSec and WebApps WGs to
take this particular text (with necessary additions to the Status of this
Document section if approved) forward to Candidate Recommendation.



I support this CfC although I am wondering about the CR exit criteria.

Do you expect to re-use the CSP1.0 criteria:

[[
The entrance criteria for this document to enter the Proposed
Recommendation stage is to have a minimum of two independent and
interoperable user agents that implementation all the features of this
specification, which will be determined by passing the user agent tests
defined in the test suite developed by the Working Group.
]]

My preference is what WebApps has used in other CRs because I think it is
clearer that a single implementation is not required to pass every test but
that at least two implementations must pass every test. F.ex.:







-Thanks, AB

Re: Call for Editor: URL spec

[Ms2ger]

On 11/06/2012 08:02 AM, Adam Barth wrote:

Does the WebApps Working Group plan do either of these things?

A) Put in technical effort to improve the specification


Unlikely.


B) License the fork in such a way as to let me merge improvements into my copy


Definitely not.

HTH
Ms2ger

Re: [WebIDL] Interface object prototype and function object

[Ms2ger]

Hi Philippe,

On 10/03/2012 05:43 PM, Philippe Le Hegaret wrote:

In
  http://dev.w3.org/2006/webapi/WebIDL/

section 4.4.1 says: "The interface object for a given non-callback
interface is a function object."

section 4 says: "If an object is defined to be a function object, then
it has characteristics as follows: Its [[Prototype]] internal property
is the Function prototype object.[...]"

Does this mean that:
  typeof Document.prototype should return "function" ?

If not, I'm wondering what I'm missing...


What you're missing is that obj.prototype doesn't return obj's 
[[Prototype]] internal property. You can get the [[Prototype]] internal 
property through Object.getPrototypeOf(obj) or obj.__proto__. In Gecko, 
at least,


w(typeof XMLHttpRequest)
w(typeof Object.getPrototypeOf(XMLHttpRequest))
w(typeof XMLHttpRequest.__proto__)

all print "function". (Using XMLHttpRequest because that's one of the 
few objects that use WebIDL-compliant bindings in Gecko.)


HTH
Ms2ger

Re: CfC: publish FPWD of DOM Parsing and Serialization; deadline Sept 11

[Ms2ger]

Hi Chaals,

On 09/17/2012 04:47 PM, Charles McCathie Nevile wrote:

On Sun, 16 Sep 2012 21:57:00 +0200, Ms2ger  wrote:


On 09/04/2012 07:06 PM, Arthur Barstow wrote:

This is a Call for Consensus to publish a First Public Working Draft of
the DOM Parsing and Serialization spec using the following ED as the
basis <http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html>.


Sorry I missed the deadline; I lost track of this CfC. Given the
standing W3C policy against forking specifications, I object to
publishing this fork.

Ms2ger


Hi Ms2ger,

the chairs and team have discussed your objection.

It is procedural, not technical.

The W3C Process and license have been available to the general public
and working group since before the work was taken on under the existing
process.

We have therefore decided to publish, according to the public
expectations agreed on as the Working Group charter.


Thank you for acknowledging the hypocrisy of this decision.

Ms2ger

Re: CfC: publish FPWD of DOM Parsing and Serialization; deadline Sept 11

[Ms2ger]

On 09/04/2012 07:06 PM, Arthur Barstow wrote:

This is a Call for Consensus to publish a First Public Working Draft of
the DOM Parsing and Serialization spec using the following ED as the
basis <http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html>.


Sorry I missed the deadline; I lost track of this CfC. Given the 
standing W3C policy against forking specifications, I object to 
publishing this fork.


Ms2ger

Re: Feedback on Quota Management API

[Ms2ger]

On 06/27/2012 05:44 PM, Tobie Langel wrote:

On Jun 27, 2012, at 6:44 AM, "Glenn Maynard"  wrote:

Unrelated, screaming-caps on RFC2119 terms (eg. "MUST") is jarring
and unnecessary.  I'd suggest dropping the em.rfc2119 style.
That's what HTML, DOM4, etc. do, and it's much more readable.


How do you distinguish between 'MUST' and 'must' then? I agree the
style is jarring, but maybe that can be fixed rather then completely
removed.


Specifications must not use RFC2119 keywords to mean anything else than 
the meaning RFC2119 assigns to those keywords.


HTH
Ms2ger

Re: [IndexedDB] Null argument for optionalParameters?

[Ms2ger]

On 06/26/2012 07:15 PM, Boris Zbarsky wrote:

On 6/26/12 12:59 PM, Joshua Bell wrote:

All that said, this seems like a common pattern. Is there something in
WebIDL I'm not seeing that implies this behavior for dictionaries
already?


No, but there have definitely been proposals (from me and Jonas at
least) that WebIDL treat null, undefined, not passed, and {} as exactly
identical for optional dictionary arguments...


This was fixed yesterday over in bug 16725; [1] see the spec. [2]

HTH
Ms2ger

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16725
[2] http://dev.w3.org/2006/webapi/WebIDL/#es-dictionary

Re: Publish FPWD of Web Intents spec; deadline June 12

[Ms2ger]

On 06/06/2012 02:26 AM, Greg Billock wrote:

On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam
  wrote:

Please refer to the email thread below

http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html

Where a consensus was reached to delete the following statement from the 
Suggestions related text.

"The User Agent should ignore the suggested services from the intent invocation if 
the user already has a handler selected."

I would like that statement to be delete before FPWD.


This is done in my local version. I have a collection of edits that
have been suggested as people have looked at the draft more closely.
I've been holding off submitting them to maintain a stable version.
Shall I go ahead and submit the edited version?


Please do; there's no point in holding off clear improvements.

Thanks
Ms2ger

Re: Push API draft uploaded

[Ms2ger]

Hi Brian,

On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote:

Thanks for the comments. I updated the spec:
- define what happens when url is omitted
- remove [NoInterfaceObject]
- define readyState as a unsigned short (that was what was meant in the first 
place)
- fix cut/paste errors

I still have to find the source of "resolve a url" as that's a function I 
borrowed from EventSource.

Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html


Thanks for the update. "resolve a url" is defined in HTML; see 
<http://www.whatwg.org/html/#resolving-urls>.


As for a numeric readyState, please have a look at the discussion at 
<http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html>.


Finally, it appears that you removed [NoInterfaceObject] from 
NavigatorPush (where I believe it was correct), rather than from 
PushService.


HTH
Ms2ger

Re: Push API draft uploaded

[Ms2ger]

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:

Thanks to the inestimable help of the W3C staff I am now plugged into
the mercurial mainline and have uploaded the first stab at the Push
API

> http://dvcs.w3.org/hg/push/raw-file/default/index.html

A couple of notes on the WebIDL:

* PushManager has
  |PushService requestRemotePermission ([Optional] DOMString url);|,
  should be ... (optional DOMString url), though the spec doesn't
  appear to define what happens when url is omitted; same for
  checkRemotePermission.
* There does not appear to be a need to make PushManager and PushService
  use [NoInterfaceObject], so please remove that.
* PushService.readyState is a DOMString, but the spec defines it to
  return the unsigned short constants CONNECTING/OPEN/CLOSED. Please
  get rid of the constants.

"The requestUrl attribute must return the absolute URL where the webapp 
server can send Push service messages to this webapp." should probably 
refer to |serviceUrl|, not |requestUrl|.


A reference to DOM4 for the DOMError interface should probably be added. 
Also, the "resolve a url" cross-reference is broken.


HTH
Ms2ger

Re: DOMParser Errors Should Be Exceptions

[Ms2ger]

On 05/23/2012 09:03 PM, Yehuda Katz wrote:

In the current DOM parsing spec[1], errors in XML (or SVG) are handled as
follows:


Let root be a new Element, with its local name set to "parsererror" and

its

namespace set to "http://www.mozilla.org/newlayout/xml/parsererror.xml";.
At this point user agents may append nodes to root, for example to

describe

the nature of the error.


In practice, browsers implement error handling in this way. The output for
the following code is given below.

(new XMLSerializer).serializeToString((new
DOMParser).parseFromString("hi", "text/xml"));

As a result, jQuery looks for a parserror tag and re-raises an error when
parsing XML[2].

In my view, the DOMParser should throw an exception, and not insert a
partially unspecified parserror tag.

Thoughts?


Opera has reported this is not web-compatible.

Ms2ger

Re: [admin] short-names and 1-liners for our 7 new FPWDs

[Ms2ger]

On 05/08/2012 09:10 PM, Arthur Barstow wrote:

4. Web Components;
<http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html>
short-name = webcomponents
1-liner = "Provides an overview of Web Components"


Maybe it would be useful to keep the "webcomponents" name for something 
normative. Also, we already have a "web" in the "w3.org" part of the 
URL, so it seems unnecessary to add another "web" in the shortname.


HTH
Ms2ger

Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

[Ms2ger]

On 05/01/2012 02:43 AM, Anne van Kesteren wrote:

On Mon, 30 Apr 2012 16:57:06 -0700, Rafael Weinstein
 wrote:

There aren't any parser changes required. DocumentFragment.innerHTML
can still provide the "fragment case" with a context element and
procede normally. It's not obvious to me what bug to open against
HTML.

Anne, can we move forward with this?


I personally think it would be better if HTML kept defining all entry
points to the HTML parser. And at least conceptually this is a new
insertion mode I think contrary to what you suggest in
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html
as only insertion modes handle emitted tokens. And although I guess it
does not matter here for now, given that the tree builder can change the
behavior of the tokenizer decoupling them seems rather odd to me.


I agree with Anne's point here; I'd rather not try to spec something 
more complex than invoking an algorithm in the HTML spec in DOMParsing.


HTH
Ms2ger

Warnings for old DOM specifications

[Ms2ger]

Hi all,

A while ago I proposed adding warnings to a number of specifications to 
alert readers that those documents are no longer being maintained. [1]


As there seemed to be general agreement this would be good to do, I've 
written up some proposed wording; see the attachment.


Please let me know if you have any comments.

Thanks
Ms2ger

[1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0245.html
Title: Warnings for old DOM specifications





Warnings for old DOM specifications

Specifications with a replacement


DOM 2 Core & DOM 2 Traversal and Range
Document Status Update 2012-##-##. This paragraph is informative. This document is not currently being actively maintained. Readers should not expect corrections and clarifications for the text to appear here or in the associated errata document. Work on the DOM4 specification, which is intended to eventually supersede this document, is currently ongoing in the Web Applications (WebApps) Working Group.



DOM 3 Core
Document Status Update 2012-##-##. This paragraph is informative.  This document is not currently being actively maintained. Readers should not expect corrections and clarifications for the text to appear here or in the associated errata document. Work on the DOM4 specification, which is intended to eventually supersede this document, is currently ongoing in the Web Applications (WebApps) Working Group.



DOM 2 Events
Document Status Update 2012-##-##. This paragraph is informative. This document is not currently being actively maintained. Readers should not expect corrections and clarifications for the text to appear here or in the associated errata document. Work on the Document Object Model Level 3 Events specification, which is intended to eventually supersede this document, is currently ongoing in the Web Applications (WebApps) Working Group.



DOM 2 Style
Document Status Update 2012-##-##. This paragraph is informative. This document is not currently being actively maintained. Readers should not expect corrections and clarifications for the text to appear here or in the associated errata document. Work on the CSS Object Model specification, which is intended to eventually supersede this document, is currently ongoing in the Cascading Style Sheets (CSS) Working Group.



DOM 2 HTML
Document Status Update 2012-##-##. This paragraph is informative. This document is not currently being actively maintained. Readers should not expect corrections and clarifications for the text to appear here or in the associated errata document. Work on the HTML5 specification, which is intended to eventually supersede this document, is currently ongoing in the HTML Working Group.




Specifications without a replacement


DOM 3 Load and Save & DOM 3 Validation
Document Status Update 2012-##-##. This paragraph is informative. The concepts this document defines have not seen adoption in web browsers and are obsolete. The Web Applications (WebApps) Working Group does not recommend its implementation. Readers who wish to pursue the use cases addressed by this specification, are encouraged to send email to public-webapps (archives).

[file-writer] WebIDL / References

[Ms2ger]

Hi all,

There are a number of bugs in the WebIDL blocks in 
<http://dev.w3.org/2009/dap/file-system/file-writer.html>.


* The 'in' token has been removed; "void append (in Blob data);" should
  be "void append (Blob data);".
* Event handlers should be "[TreatNonCallableAsNull] Function? onfoo",
  not just "Function".
* Interfaces should not have [NoInterfaceObject] without a good reason.
* FileException doesn't exist anymore; use DOMException.

Also, the References section is severely out of date.

HTH
Ms2ger

[FileAPI] Various comments

[Ms2ger]

Hi Arun,

I've read the File API specification, and have a number of comments:

== 1. Introduction ==


"Binary Large Object" -- a name originally introduced to web APIs in Google 
Gears


should use an en dash (—, U+2013) instead of two hyphens.

This paragraph is inconsistent about linking File and Blob to their 
definitions.


The example has

>  if(evt.target.error.name == "NOT_READABLE_ERR") {

which probably should be "NotReadableError".

== 2. Conformance ==

I think it's surprising that notes are normative, unlike (AFAICT) most 
other Web API specifications.


== 4. Terminology and Algorithms ==

The >= and <= operators don't seem to be used in the specification.

== 6. The Blob Interface ==

The constructor can use the new WebIDL unions types, as

> Constructor((ArrayBuffer or Blob or DOMString)[] blobParts,
> optional BlobPropertyBag options)

=== 6.1. Constructors ===

The reference to ES5 doesn't seem necessary.

=== 6.2. Attributes ===


On getting, conforming user agents SHOULD return the MIME type of the Blob, if 
it is known.


Should be MUST, as we already have "if it is known".

=== 6.3. Methods and Parameters ===

The contentType normalization should not special-case undefined; if an 
author passes undefined, it should be treated as "undefined" per WebIDL.


== 7. The File Interface ==

Something's weird with the indentation in the IDL block here.


readonly attribute Date lastModifiedDate;


should be "Date?", as it can return null.

== 8. The FileReader Interface ==
=== 8.1. The FileReader Task Source ===


The FileReader interface enables asynchronous reads on individual
Blob objects by firing progress events as the read occurs to event
handler methods on the FileReader, which is an EventTarget
[DOMCore].


This seems to suggest that one can only use the event handler methods 
(attributes?), but not add/removeEventListener. Maybe just remove to 
"event handler methods".


=== 8.5. Reading a File or Blob ===

The result attribute should probably be declared as

| readonly attribute (DOMString or ArrayBuffer)? result;

 8.5.7. Blob Parameters 

I have no idea what this section is actually supposed to define.

= 8.5.9.1. Event Summary =

> … the table below is normative for the events in this specification.

The table should not be normative; the events are already fired in the 
respective algorithms.


= 8.5.9.2. Summary of Event Invariants =

> The following are normative invariants …

What are "normative invariants"? This seems to be a list of statements 
of fact [1], and as such should be informative.


== 10. Errors and Exceptions ==
=== 10.1. Throwing an Exception or Returning an Error ===


Synchronous read methods throw exceptions of the type in the table
below if there has been an error with reading or .


Or?

The EncodingError cell seems to confusingly use "encoding" for a concept 
related to the length of a data URL and character encodings; I don't see 
how these concepts are related.


== 11. A URI for Blob and File reference ==
=== 11.1. Requirements for a New Scheme ===

This section uses |img| and  inconsistently, it should use the former.

=== 11.2. Discussion of Existing Schemes ===


Choosing a name that clarifies the primary use case -- namely, access
to memory-resident Blob resources -- is a worthwhile compromise, and
favors clarity, familiarity, and consistency across the web platform.


En dashes again.

=== 11.3. Definition of blob URI Scheme ===


Opaque strings MUST NOT include any reserved characters from
[RFC3986] without percent-encoding them; these characters MUST be
percent-encoded.


Redundant requirements.

=== 11.6. Lifetime of Blob URIs ===

Should reference the oneTimeOnly argument here.

=== 11.8. Creating and Revoking a Blob URI ===

// Window implements URL;
// WorkerUtils implements URL;

Those statements are out of place, and don't mean what they seem to. 
Instead, they would require createObjectURL and revokeObjectURL to exist 
on the Window and WorkerUtils interfaces.


=== 11.9. Examples of Blob URI Creation and Revocation ===


Blob URIs are strings that dereference Blob objects, and can persist
for as long as the document from which they were minted using
URL.createObjectURL() -- see _Lifetime of Blob URIs_.


En dash, and the "Lifetime of Blob URIs" link is broken.

> In the example below, two Image elements

Should say "|img| elements" for consistency.

== 16. References ==

Aryeh Gregor is now also editing DOM Core, which has been renamed to DOM4.

The URL specification is now at 
<http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html>.


The "Stream API" reference has a broken link.

HTH
Ms2ger

[1] http://ln.hixie.ch/?start=1140242962&count=1

[clipboard] Event definition

[Ms2ger]

Hi Hallvord,

At 
<http://dev.w3.org/2006/webapi/clipops/clipops.html#clipboard-event-interface>, 
a reference to DOM *2* Events is made; it should be updated.


Also, the initClipboardEvent method should be removed in favour of a 
constructor, as described at 
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events>.


HTH
Ms2ger

Re: CfC: Charter addition for Fullscreen API

[Ms2ger]

On 01/31/2012 05:04 PM, Robin Berjon wrote:

Fullscreen API


Support.

Re: Obsolescence notices on old specifications, again

[Ms2ger]

On 01/24/2012 08:33 PM, Glenn Adams wrote:

The problem is that the proposal (as I understand it) is to insert
something like:

"DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."

This addition is tantamount (by the reading of some) to demoting the status
of DOM2 to "a work in progress".


Not at all; it's a work on which progress has stopped long ago.

Re: Obsolescence notices on old specifications, again

[Ms2ger]

On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote:

* Ms2ger wrote:

The recent message to www-dom about DOM2HTML [1] made me realize that we
still haven't added warnings to obsolete DOM specifications to hopefully
avoid that people use them as a reference.


If you want to say more than that the specifications are no longer being
maintained and which newer specifications might contain more recent de-
finitions for the features covered you will have to create a process for
that first (it would require Advisory Committee review for instance, as
otherwise you are likely to create unnecessary drama).


I should have been clearer; this is indeed all I intend to say.

HTH
Ms2ger

Obsolescence notices on old specifications, again

[Ms2ger]

Hi all,

The recent message to www-dom about DOM2HTML [1] made me realize that we 
still haven't added warnings to obsolete DOM specifications to hopefully 
avoid that people use them as a reference.


I propose that we add a pointer to the contemporary specification to the 
following specifications:


* DOM 2 Core (DOM4)
* DOM 2 Views (HTML)
* DOM 2 Events (D3E)
* DOM 2 Style (CSSOM)
* DOM 2 Traversal and Range (DOM4)
* DOM 2 HTML (HTML)
* DOM 3 Core (DOM4)

and a recommendation against implementing the following specifications:

* DOM 3 Load and Save
* DOM 3 Validation

Hearing no objections, I'll try to move this forward.

Ms2ger

[1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html

Re: [XHR] responseType "json"

[Ms2ger]

On 01/06/2012 10:28 PM, Jarred Nicholls wrote:

This is an editor's draft of a spec, it's not a recommendation, so it's
hardly a violation of anything.


With this kind of attitude, frankly, you shouldn't be implementing a spec.

HTH
Ms2ger

Re: CfC: publish WG Note of the "old" XHR(1); deadline December 8

[Ms2ger]

On 12/01/2011 08:25 PM, Arthur Barstow wrote:

Adrian proposed the old XHR(1) spec be published as a WG Note (to
clearly state work on that spec has stopped) and this is a Call for
Consensus to do so.

If you have any comments or concerns about this proposal, please send
them to public-webapps by December 8 at the latest.

As with all of our CfCs, positive response is preferred and encouraged
and silence will be assumed to be agreement with the proposal.


Sure, as long as TR/XMLHttpRequest/ redirects to XHR2 and there is a 
clear link to it from the note.


Ms2ger

Re: [DOM4] atomicity of DocumentFragment insertion

[Ms2ger]

On 10/29/2011 01:32 AM, Jonas Sicking wrote:

(cc'ing webapps as that's the proper list to discuss the DOM. Yes,
it's confusing).


It isn't, as noted in the SotD: 
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#sotd>.


HTH
Ms2ger

[indexeddb] 'raises' statements in IDL

[Ms2ger]

Hi all,

I noticed that the IDB spec still uses 'getraises' and 'raises'
statements in the IDL code. These were removed in bug 13866 [1].

HTH
Ms2ger

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13866

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

[Ms2ger]

Hi Art, all,

On 10/14/2011 09:27 PM, Arthur Barstow wrote:

The people working on the D3E spec (namely Jacob, Doug and Olli) propose
below that the spec be published as a Candidate Recommendation and this
is a CfC to do so:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

The comment tracking document for the last LCWD is:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html

This CfC satisfies: a) the group's requirement to "record the group's
decision to request advancement" to CR; and b) "General Requirements for
Advancement on the Recommendation Track" as defined in the Process
Document:

http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

The exit criteria has not yet been added to the ED and I request the
Editors to please propose the specific criteria in response to this
e-mail before the comment deadline. It is my expectation that Microsoft
and Mozilla will complete the test suite [TS] they started and they will
implement this CR. As such, I assume the exit criteria will include a
requirement that at least two independent implementations pass all of
the test cases.

As with all of our CfCs, positive response is preferred and encouraged
and silence will be considered as agreeing with the proposal. The
deadline for comments is October 21 and all comments should be sent to
www-dom at w3.org.


I used to think that the right approach to DOM 3 Events was to get it 
published as a Recommendation as soon as possible, and start to work on 
a higher-quality specification when that happened. However, for various 
reasons, I've changed my mind, and now think that we should make DOM 3 
Events a specification of the quality that is now expected from 
specifications.


Furthermore, I believe a lot of good work has been put into 
specification, and hope we can move forward with it soon.


However, *I do object to the publication* of this specification because 
the inappropriate resolution of the following issues (in no particular 
order):


First (issue 123), it contradicts an uncontested requirement [1] in DOM4 
forbidding the minting of new DOM feature strings, as reported by Anne. [2]


Second (issue 179), it ignores the consensus about using DOMException 
instead of custom exception types like EventException, as noted in 
WebIDL, [3] which I reported. [4]


Third (issue 130), the resolution made to add an informative WebIDL 
appendix is insufficient. Not only did the editors not list any 
technical reason for this decision in their reply, [5] despite this 
being required by the Process document. [6]


The only claim that I could find in favour of this decision is that 
WebIDL is not stable. [7] However, WebIDL's second LC has ended 
(without, as far as I can tell, too many comments), and as such it is as 
stable as DOM 3 Events itself, and is indeed moving ahead at a rather 
much faster pace.


Furthermore, the DOM 3 Events specification already (stealthily [8]) 
depends on the HTML specification, which is even less stable than WebIDL.


In fact, it is not clear to me what there is to gain by not referencing 
WebIDL normatively. In reality, browsers will have to ignore the 
normative IDL code and use the WebIDL instead. In effect, not 
referencing WebIDL will only make DOM 3 Events *seem* more stable then 
it actually is. (I note that the specification doesn't actually define 
which IDL dialect it uses, though the references section lists OMG IDL.)


I am ready to reconsider my objection once the issues I mentioned above 
are fixed.


Of course, if the editors would welcome this, I am happy to offer my 
help in editing the specification.


Thanks
Ms2ger

[1] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-features
[2] http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0107.html
[3] http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions
[4] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0087.html
[5] http://lists.w3.org/Archives/Public/www-dom/2011AprJun/0066.html
[6] http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address
[7] http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0156.html
[8] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0094.html

[FileAPI] Event handler IDL attributes

[Ms2ger]

Hi Jonas, Arun

As described in bug 13433 [1], the type of event handler IDL attributes 
should be "[TreatNonCallableAsNull] Function?". Could you change File 
API accordingly?


Thanks
Ms2ger

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13433

Re: Mutation Observers: a replacement for DOM Mutation Events

[Ms2ger]

On 09/29/2011 04:32 PM, Doug Schepers wrote:

Hi, Adam-

I'm glad to see some progress on a replacement for Mutation Events.

Would you be interested in being the editor for this spec? It's already
in our charter, we just need someone to take it up. Olli has offered
offlist to be a co-editor, so between the two of you, I think it would
be pretty manageable.

I'd be happy to help get you started.


I repeat my objections to speccing this outside DOM4. I would, of 
course, welcome Olli or Adam to become co-editors if they would wish that.


Ms2ger

Re: Adding Web Intents to the Webapps WG deliverables

[Ms2ger]

On 09/20/2011 11:27 PM, Bjoern Hoehrmann wrote:

with the Web Applications Working Group, which after six years has a
XMLHttpRequest test suite consisting of nothing but "There is a good
chance a test suite for XMLHttpRequest will be placed around here" and
no XMLHttpRequest specification to show.


http://www.w3.org/TR/XMLHttpRequest/
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Ms2ger]

expect the set-up to be rather brittle.


Furthermore, if anyone wishes to step forward to help editing a 
Web-relevant specification, I would suggest they have a look at the 
"Specification TODO" page [1], which lists a number of technologies 
where their help is much more urgently needed. If they rather work on 
what is currently in DOM Core, however, I sure we can figure something 
out to make that possible.


To answer your questions above: you seem to have forgotten my preferred 
approach, to define the mark-up-language-, style-, and 
network-independent parts of the DOM (the core parts, I would suggest), 
which happen to be rather tightly coupled, in the DOM Core 
specification. As I've mentioned earlier, this reduces unnecessary 
overhead and increases the time editors can spend on technical, rather 
than procedural, matters. That can only be good for the Web, right? As 
for my availability and willingness to edit the specification; these are 
lessened each time I have to spend time on procedural and editorial 
matters, but I'm still willing to continue editing DOM Core.


Thank you for your thoughtful message
Ms2ger

[1] http://wiki.whatwg.org/wiki/Specifications_TODO

Re: More questions about contextual reference nodes

[Ms2ger]

On 04/09/2011 07:14 PM, Boris Zbarsky wrote:

On 4/9/11 6:27 AM, Lachlan Hunt wrote:

I also have to include one for HTMLCollection, which doesn't inherit
from NodeList.


Yeah, that's broken... I wonder whether we can just fix that in Web DOM
Core or something


If people are willing to implement that, certainly.

--
Ms2ger