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 <t...@tink.uk> wrote:
> Hello,
>
> There will be
aised, 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
vide 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
-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
is 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/
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-
iQEcBAEB
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 `REA
Hi Yves,
On 09/01/2015 11:30 AM, Yves Lafon wrote:
> On 31 Aug 2015, at 20:12, Ms2ger <ms2...@gmail.com> 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
plemented).
>
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
NV5VSxq1H2aHv6rdRiBNygeGzEiwENZ
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
-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
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
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
and specification issues.
* Cross-referencing commits/PRs with issues might also be useful.
HTH
Ms2ger
. 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
precludes the author from using custom elements in HEAD.
Except the HTML parser. Unknown elements imply /headbody. Feel free
to use the Live DOM Viewer to confirm that.
HTH
Ms2ger
[1] http://software.hixie.ch/utilities/js/live-dom-viewer/
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
group that will insist on imposing a more restrictive
copyright on it.
HTH
Ms2ger
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
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
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
: EventTarget {
// …
readonly attribute IDBReadyState readyState;
// …
};
HTH
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
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
doc.
Please revert all those changes.
Thank you
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
://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
Thanks
Ms2ger
a link to
the source in the dl in the header.
Thanks
Ms2ger
with the proposal.
*sigh*
Same objections as to the XHR WD.
Ms2ger
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
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,
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
one of the
few objects that use WebIDL-compliant bindings in Gecko.)
HTH
Ms2ger
Hi Chaals,
On 09/17/2012 04:47 PM, Charles McCathie Nevile wrote:
On Sun, 16 Sep 2012 21:57:00 +0200, Ms2ger ms2...@gmail.com 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
of this CfC. Given the
standing W3C policy against forking specifications, I object to
publishing this fork.
Ms2ger
.
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
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
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
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
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
, 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
. 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
not try to spec something
more complex than invoking an algorithm in the HTML spec in DOMParsing.
HTH
Ms2ger
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
,
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
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=1140242962count=1
-file/tip/Overview.html#constructing-events.
HTH
Ms2ger
On 01/31/2012 05:04 PM, Robin Berjon wrote:
Fullscreen API
Support.
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
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.
no objections, I'll try to move this forward.
Ms2ger
[1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
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
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
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
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
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
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
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
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.
DOM Core.
Thank you for your thoughtful message
Ms2ger
[1] http://wiki.whatwg.org/wiki/Specifications_TODO
to implement that, certainly.
--
Ms2ger
61 matches
Mail list logo
