h 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
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.
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
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
urse, 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/#id
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
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
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 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
ng no objections, I'll try to move this forward.
Ms2ger
[1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
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 tha
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".
On 01/31/2012 05:04 PM, Robin Berjon wrote:
Fullscreen API
Support.
mcore/raw-file/tip/Overview.html#constructing-events>.
HTH
Ms2ger
roken.
> 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
;[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
et 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
Docume
'd rather not try to spec something
more complex than invoking an algorithm in the HTML spec in DOMParsing.
HTH
Ms2ger
s" 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
;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
p
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
ng-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
ggested 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
e 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/w
#x27;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
track of this CfC. Given the
standing W3C policy against forking specifications, I object to
publishing this fork.
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
_)
all print "function". (Using XMLHttpRequest because that's one of the
few objects that use WebIDL-compliant bindings in Gecko.)
HTH
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
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, A
ed 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
proposal.
*sigh*
Same objections as to the XHR WD.
Ms2ger
e to see a link to
the source in the dl in the header.
Thanks
Ms2ger
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
Thanks
Ms2ger
R 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
he 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
cient 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-fil
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
quot; };
interface IDBRequest : 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
ishing this freely licensed specification in
a working group that will insist on imposing a more restrictive
copyright on it.
HTH
Ms2ger
ther 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
. 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/
t 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
rence test suite issues
and specification issues.
* Cross-referencing commits/PRs with issues might also be useful.
HTH
Ms2ger
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-pointerl
this Working Group has published a
specification [1] for it.
HTH
Ms2ger
[1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
-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-
iQEcBAEBAgAGBQJ
ribute 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
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
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 stabl
; 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 add
ument 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
nt 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+Nxxnmg0BXfIOyS
-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
USJwyL5EUwkPRO9iqZF4LthfgkvdDJ7
e 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
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+Hac
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 meet
willing to implement that, certainly.
--
Ms2ger
61 matches
Mail list logo
