[D3E] Draft minutes from 7-May-2013 call [Was: Re: WebApps DOM3 Events Wiki page]
[ Sorry for the cross-posting. Going forward, let's please use www-dom for D3E discussions, minutes, etc. ] On 5/7/13 9:06 PM, ext Travis Leithead wrote: Hey folks, I just posted the raw minutes to the DOM 3 Events wiki page: http://www.w3.org/2008/webapps/wiki/DOM3Events http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings The page itself is a derelict from ages past, and I haven’t made much of an effort to clean it up, but it does have a new section for Meetings, and a place to propose an agenda. The minutes span the mightnight rollover on some server, so they are not contiguous, and I failed to find a way to automatically stich them together, so they are in two parts. Art, I’d love any pointers to how to clean them up… J I merged the two IRC logs into minutes http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html, copied below. (I'll try to get someone from the Team to copy these minutes to `date space` i.e. .../05/07-webapps-minutes.html.) -AB W3C http://www.w3.org/ - DRAFT - DOM 3 Events 07 May 2013 Agenda http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0076.html See also:IRC log http://www.w3.org/2013/05/07-webapps-irc Attendees Present Travis_Leithead, Gary_Kacmarcik, Masayuki_Nakano, Wez(Google), Takayoshi_Kochi Regrets Chair Travis Scribe Travis Contents * Topics http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#agenda 1. spec update http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#item01 2. Bugs! http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#item02 * Summary of Action Items http://lists.w3.org/Archives/Public/www-archive/2013May/att-0014/DOM-3-Events-07-May-2013.html#ActionSummary garykac:Call the W3C Bridge instead of the info I sent you... 6177616200 masayuki:You alive? masayuki Travis: Yes. Thank you for inviting me. scribe Scribe: Travis scribe ScribeNick: Travis real_wez Hello all garykac travis: start by creating an agenda garykac travis: then we need to talk about timelines for action items garykac start with spec update spec update garykac started with existing dom3 spec garykac:... was being edited by hand. Required tedius changes ... coverted to ReSpec ... (with no changes) ... Then changed to ReSpec IDL ... Fixed some typos ... JS expands out the table now. ... waiting for new repro to be ready ... then we can start adding/explaining existing stuff ... CVS repo is moving to Mercurial for ease/convenience ... masayuki found some errors where some things weren't labelled ... this will put us in a better position moving forward. ... Found 15/20 issues that still need to be filed in bugzilla. ... a couple are significant, I can talk about them here once we get through our other items. ... the ReSpec is sittting locally... ... should be only a few days till it's ready. I'd like to just wait until the Repro is ready to check it in. Anything else on this topic? garykac:Should be it; waiting until spec is ready before filing the next round of issues. Bugs! https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=DOM3%20Eventsresolution=---list_id=10169 I see 27 bugs, plus the 15/20 that Gary will deposit soon I'd like a call for discussion on any of these bugs? masayuki:Do you have any you'd like to talk about? masayuki Yeah, there are a lot of issues for naming .key values. masayuki If browser venderos can name it originally, it will break compatibility between browsers in the future. garykac:We might get into bikeshedding on those... ... are there any larger issues? masayuki Is vender prefixed name better for not predefined key names? garykac I would rather define them in the spec if at all possible. wes:Direction we were thinking with not defined key names is to add them into the spec; vendor prefixes are dangerous because they persist. garykac It's hard to remove vender prefix once the've been added to some implementations. real_wez:One topic to split up the key table into sections. masayuki I think that web apps can remove vender prefix before comparing the values, that is difference from CSS's vendor prefix. real_wez:yes, garykac had some thoughts on how to do this... ... like color keys (red,blue,...) ect. seems reasonable to have a key value for those ... right now, they're just all mixed into the jumbo table. ... garykac wanted to split into sections. garykac:Right now the key table was one gigantic table. ... there was categories, but it didn't help much ... additionally, we're going to want to augment this table over time ... e.g., there's the Android bug to map the keys to Android.. masayuki And I want a rule for browser vendoers who want to add new
[XHR] anonymous flag
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight and the same-origin resource
will have to opt in to receiving that custom header? Expected?
var xhr=new XMLHttpRequest({anonymous:true})
xhr.open('GET', '/')
xhr.setRequestHeader('X-foo', '')
xhr.send() // fails unless same-origin server has CORS enabled and opts-in to
X-foo header
At least by my reading of the current spec.
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: [XHR] anonymous flag
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: If create an anonymous XHR request, rig it to GET a same-origin resource and set a custom header, it will trigger a preflight and the same-origin resource will have to opt in to receiving that custom header? Expected? Yes. It was added to address: http://www.w3.org/TR/UMP/ However, Gecko currently implements a mozAnon thingie that only omits credentials and does not do the origin/referrer source nullifying. It also hasn't gained any traction beyond that with implementers so maybe it should be removed for now. Dunno. -- http://annevankesteren.nl/
Web SQL and SQL
While researching the feasibility of using Web SQL for an internal project, I
was taken aback by the use of raw SQL strings - I thought as an industry we had
moved past that horrid hack :)
My understanding is that Web SQL presents a simplified means of storing and
retrieving relational data in the client for offline storage, and it isn't as
though they need OLAP cubes, so allowing freeform SQL seems a bit dangerous -
and leaves the spectre of implementation incompatibilities (like present-day
SQL) free to stalk again.
The main thing that concerns me is the risk of SQL injection - many of us are
veterans of VBScript and PHP code that is wide-open (e.g. SELECT * FROM
accounts WHERE username = $_POST['user']) so I'm surprised the current
specification gives us a simple hand-waving dismissal: Authors are strongly
recommended to make use of the ? placeholder feature of the executeSql()
method, and to never construct SQL statements on the fly..
I'd like to propose that the executeSql method be completely removed and
replaced with individual functions that can be used to work with relational
data in a safe, efficient manner. Please excuse the bias visible from my email
address domain, but I think our Linq library is a good approach to follow, for
example:
db.from( tableName ).where( c, function(value) { return value 5; }
).orderBy( c).select(a, b, d);
is safer than letting developers, who span a huge gamut of competence, play
with fire, for example:
var c = prompt(which column?);
tx.executeSql(SELECT a, b, d FROM tableName WHERE + c + 5 ORDER BY +
c);
Joins and other complex queries can be done:
db.from(tableFoo).join(tableBar, a, g).select(tableFoo.a,
tableBar.g);
Seeming as aggregate operations (e.g. SUM, AVG, etc) are known to the
implementation they can also be exposed directly:
db.from(tableFoo).where(c, function(value) { return value 5; }).sum();
This approach can be extended to replace the other core SQL statements, e.g..:
db.update(tableName).where( c, function(value) { return value == 5; }
).select(a, b, d).set( 5, 7, 13 );
db.insert(tableName).select(a, b, d).set( 5, 7, 13 );
db.delete(tableName).where( c, function(value) { return value 5; });
This approach has the advantage of providing syntax checking when the script is
interpreted by the browser (rather than waiting for the SQL string to be
executed first, which might never happen), making it impossible to perform
SQL-injection attacks. This proposed API requires no introduction of new
ECMAScript language features either (though not to be confused with the Linq
language extensions to C# and VB.NET). It also eliminates SQL's
counter-intuitive syntax which puts the SELECT projection before the sources,
predicates and joins - something that led to no end of confusion when I was
starting-off with SQL.
Re: Web SQL and SQL
On Tue, May 7, 2013 at 8:20 PM, Dai Rees dr...@microsoft.com wrote: While researching the feasibility of using Web SQL for an internal project, I was taken aback by the use of raw SQL strings - I thought as an industry we had moved past that horrid hack :) We have, in a way. Web SQL is dead. -- http://annevankesteren.nl/
Re: Web SQL and SQL
WebSQL is dead. See
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0451.html.
- Kyle
On Tue, May 7, 2013 at 8:20 PM, Dai Rees dr...@microsoft.com wrote:
While researching the feasibility of using Web SQL for an internal
project, I was taken aback by the use of raw SQL strings - I thought as an
industry we had moved past that horrid hack :)
My understanding is that Web SQL presents a simplified means of storing
and retrieving relational data in the client for offline storage, and it
isn't as though they need OLAP cubes, so allowing freeform SQL seems a bit
dangerous - and leaves the spectre of implementation incompatibilities
(like present-day SQL) free to stalk again.
The main thing that concerns me is the risk of SQL injection - many of us
are veterans of VBScript and PHP code that is wide-open (e.g. SELECT *
FROM accounts WHERE username = $_POST['user']) so I'm surprised the
current specification gives us a simple hand-waving dismissal: Authors are
strongly recommended to make use of the ? placeholder feature of the
executeSql() method, and to never construct SQL statements on the fly..
I'd like to propose that the executeSql method be completely removed and
replaced with individual functions that can be used to work with relational
data in a safe, efficient manner. Please excuse the bias visible from my
email address domain, but I think our Linq library is a good approach to
follow, for example:
db.from( tableName ).where( c, function(value) { return value 5; }
).orderBy( c).select(a, b, d);
is safer than letting developers, who span a huge gamut of competence,
play with fire, for example:
var c = prompt(which column?);
tx.executeSql(SELECT a, b, d FROM tableName WHERE + c + 5 ORDER BY
+ c);
Joins and other complex queries can be done:
db.from(tableFoo).join(tableBar, a, g).select(tableFoo.a,
tableBar.g);
Seeming as aggregate operations (e.g. SUM, AVG, etc) are known to the
implementation they can also be exposed directly:
db.from(tableFoo).where(c, function(value) { return value 5;
}).sum();
This approach can be extended to replace the other core SQL statements,
e.g..:
db.update(tableName).where( c, function(value) { return value == 5; }
).select(a, b, d).set( 5, 7, 13 );
db.insert(tableName).select(a, b, d).set( 5, 7, 13 );
db.delete(tableName).where( c, function(value) { return value 5; });
This approach has the advantage of providing syntax checking when the
script is interpreted by the browser (rather than waiting for the SQL
string to be executed first, which might never happen), making it
impossible to perform SQL-injection attacks. This proposed API requires no
introduction of new ECMAScript language features either (though not to be
confused with the Linq language extensions to C# and VB.NET). It also
eliminates SQL's counter-intuitive syntax which puts the SELECT projection
before the sources, predicates and joins - something that led to no end of
confusion when I was starting-off with SQL.
Re: [Gamepad] spec status
On 5/2/2013 12:23 PM, Florian Bösch wrote: I'd like to note that the current semantic (in google chrome) of press button to connect device is not very user friendly. Not all buttons register as buttons (some register as axes) and won't do anything. Some devices are also devoid of buttons (like the oculus rift) to press. I believe my current implementation in Firefox allows interacting with either a button or an axis. The downside to that is that it's not great unless you also implement deadzones for axes, otherwise you can wind up accidentally sending input to pages. I don't think devices like the Oculus Rift are in scope for this spec, we've explicitly stated that we're only attempting to spec interaction with gamepad devices that are comprised of buttons and axes. -Ted
Re: [Gamepad] spec status
I think the user unfriendlyness derives from that you can't open that page which you've played before and have it just work. Maybe the UA could remember the devices you enabled?
CfC: Shelve Web Intents, Web Intents Addendum, Pick Media Intent, Pick Contacts Intent, respond by 17 May (next Friday) (resend)
(resend to include Web Intents TF list and WebApps list for shelving Web Intents spec, as well as DAP for all of specs) --- This is a Call for Consensus (CfC) to shelve the Web Intents, Web Intents Addendum, Pick Media Intent, and Pick Contacts Intent specifications (4 specs). Shelving in this case means that we are not sure the specifications will advance along the lines the drafts indicate. As a result we want to be clear to everyone that we may not advance the specifications or that we may change the approach. This does not mean that we have decided not to advance them, just that there is a question as to the direction and/or progression at this point. In order to advance this work we need support for the underlying technology, which we have been assuming will be a combination of Web Intents and Web Activities. This will require some sharing of proposals on the public list to enable progress. It would be best if we can progress this on the public list by September, so that we can have a meaningful result on the topic at a TPAC F2F. If we have consensus to shelve the documents, this will have the following immediate consequences: 1. The editors will edit each document to add a warning statement before the abstract. I suggest we use the following text (feel free to make suggestions): The Device APIs Working Group is currently not progressing the approach outlined in this draft. Please treat this document with caution and do not reference it or use it as the basis for implementation. The domain covered by this document is still within the scope of the Working Group as defined in its Charter. The Working Group may resume this work or adopt an alternative approach depending on the interest of WG members and implementers. 2. On the DAP home page we will move the specifications from the active roadmap [1] to the list of shelved specifications [2]. I suggest we keep both the links to the latest published draft and editors draft available when we do this. (I can volunteer to make this update if we agree to this CfC). Please send all comments regarding this CfC to the public-device-a...@w3.org mail list by 17 May (next Friday). Silence will be considered as agreement with the proposal. If you support this CfC, a positive response is preferred and encouraged, even if a +1. Obviously any constructive work on the list regarding the underlying technology would also be welcome. Thanks regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group [1] http://www.w3.org/2009/dap/#roadmap [2] http://www.w3.org/2009/dap/#shelved
Re: [XHR] anonymous flag
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl: On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: If create an anonymous XHR request, rig it to GET a same-origin resource and set a custom header, it will trigger a preflight and the same-origin resource will have to opt in to receiving that custom header? Expected? Yes. It was added to address: http://www.w3.org/TR/UMP/ I'm not sure what use cases having this feature in XHR solves.. So I would support removing it, unless we can demonstrate its value. However, Gecko currently implements a mozAnon thingie that only omits credentials and does not do the origin/referrer source nullifying. It also hasn't gained any traction beyond that with implementers so maybe it should be removed for now. Dunno. -- http://annevankesteren.nl/
Re: Fetch: HTTP authentication and CORS
On 7 mai 2013, at 02:23, HU, BIN wrote: Because nonce is needed to generate the appropriate digest, the 401 challenge is required. So the lesson here is: any developer that intends to use authenticated XHR should always start with an XHR that is a simple ping-like GET, then do the real things. Right? Paul
Re: Rough summary of minutes from the face to face
Chaals I think this is very helpful and useful. It makes the status, activity and important items very visible in a concise manner. Much appreciated, thanks. regards, Frederick Frederick Hirsch Nokia On May 7, 2013, at 6:16 AM, ext Charles McCathie Nevile wrote: Hi, in line with the last item on this list, I committed to make a rough summary of the meeting available to go with the raw minutes. The idea is that people who aren't in the group and weren't there can actually understand what the minutes mean. So here it is. Minutes for Thursday[2] and Friday[2] are available Notes on the topics listed in the minutes: Thursday =Dashboard / PubStatus Webapps maintains a wiki page[4] with the latest knowledge about the specs the group is working on. =App Manifest This is a manifest for packaged (i.e. an installable zip) or hosted (something like pages with an appcache manifest) apps, that provides metadata, an icon, etc. It will be moved from the Sysapps group to the web apps group, who already have it as an explicit charter deliverable. There is a comparison chart[5] of Manifest formats available (but not 100% correct - I believe contributions are welcome. =AppCache There are two initial proposals for fixing it, one from Mozilla[6], and one expected from Google based on Navigation Controller[7]. A key question is whether to have a declarative format (Jonas' proposal has a JSON format that is more or less declarative, Navigation Controller is just script). NB Since the meeting we have started to collect use cases[8] in our Wiki =Indexed DB Hopefully version 1 will be finished in a few months. It seems the last point of disagreement was resolved at the meeting, so we expect a new draft in a couple of weeks that will be more or less the final one. =DOM3 Events - Status Update Keyboard events are known to be difficult to standardise. They don't have enough tests to be confident that they have this part right, and want more. Maybe they will be ready some time around the end of the year. =Web Components There are now 4 specifications that are being developed to allow the creation of custom elements in HTML (and XHTML). The work is led by Dmitry Glazkov from Google. There was an introduction to the various specs, where they fit and where they are up to. =Web Components Security Model, CORS, CSP This was a brief discussion with the Web App Security working group, just describing basic things and meeting the people. =IME This specification is meant to allow use cases including writing a custom IME to replace the system one (like what we do for translate), to make sure that it is easier to interact cleanly with IME when doing something like suggest, etc. There was a joint meeting with an accessibility group, but they were more concerned about building editors (which is very hard) than actual IME (which is moderately hard, unless you can't interact with the native one which makes it horribly hard). =File API Mozilla has a new proposal[9] (as of the morning of the meeting). FileAPI has a few outstanding issues, and is likely to try and ship rather than updating to use futures, ... =WebIDL This probably only matters for people writing specs. WebIDL level 1 is likely to be finished in a few months, with level 2 work ongoing. Friday =Testing, Move to Github The Web needs more tests. There are occasional Test The Web Forward events where people make them. W3C is moving its test infrastructure to use a single github repository for everything. =Progress Events These are used by XHR, the img element, and the Sysapps messaging API. The spec should be finalised in summer =XMLHttpRequest There will be a level 1 specification that describes the interoperable bits, to be finalized this year. Work will continue on level 2, with CORS, authentication, etc, aiming to be done by late 2014. =Coordination (TC39) There has been a discussion asking for more coordination with TC39 for things like making sure that when new APIs are developed at W3C (e.g. in Webapps) there is a notice to them so they can give an early review on things like whether the API looks like normal Javascript, not something mostly designed as if it were in C++ or some other language. The conclusion was Please do more coordination. [1] http://www.w3.org/wiki/Webapps/April2013Meeting [2] http://www.w3.org/2013/04/25-webapps-minutes.html [3] http://www.w3.org/2013/04/26-webapps-minutes.html [4] http://www.w3.org/2008/webapps/wiki/PubStatus [5] http://www.w3.org/community/webappstore/wiki/Manifest [6] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html [7] https://github.com/slightlyoff/NavigationController [8] http://www.w3.org/wiki/Webapps/AppCacheUseCases [9] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0382.html I'm interested in whether this was a useful
RE: Fetch: HTTP authentication and CORS
That is correct. Thanks Bin From: Paul Libbrecht [mailto:p...@hoplahup.net] Sent: Wednesday, May 08, 2013 1:14 PM To: HU, BIN Cc: Hallvord Reiar Michaelsen Steen; Jonas Sicking; Anne van Kesteren; WebApps WG; WebAppSec WG Subject: Re: Fetch: HTTP authentication and CORS On 7 mai 2013, at 02:23, HU, BIN wrote: Because nonce is needed to generate the appropriate digest, the 401 challenge is required. So the lesson here is: any developer that intends to use authenticated XHR should always start with an XHR that is a simple ping-like GET, then do the real things. Right? Paul
Re: [XHR] anonymous flag
On Wed, May 8, 2013 at 1:07 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl: Yes. It was added to address: http://www.w3.org/TR/UMP/ I'm not sure what use cases having this feature in XHR solves.. So I would support removing it, unless we can demonstrate its value. We could revisit http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171 I suppose. Apparently at least Jonas changed his mind since then. Dunno about others. -- http://annevankesteren.nl/
