Proposal for a web application descriptor
Hello everyone, I have read a lot in the last month about the future of html and web applications and I am very impressed by the progress this makes. However, I have come across some thing that annoys me: Permissions. I know they are important and I know they are needed but currently I find this quite inconvenient. And with more and more permissions coming up this might get worse so I spent some time thinking about it. I have written a short document covering my proposal: www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or www.simonheckmann.de/proposal/ (HTML version). It should just take only a few minutes to read and includes examples and screenshots. I am really looking forward to hearing your thoughts on this. Please feel free to share this idea with whomever you want to. If you think I should post this proposal somewhere else please say so. Kind regards, Simon Heckmann
Proposal for a web application descriptor
Hello everyone, I have read a lot in the last month about the future of html and web applications and I am very impressed by the progress this makes. However, I have come across some thing that annoys me: Permissions. I know they are important and I know they are needed but currently I find this quite inconvenient. And with more and more permissions coming up this might get worse so I spent some time thinking about it. I have written a short document covering my proposal: www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or www.simonheckmann.de/proposal/ (HTML version). It should just take only a few minutes to read and includes examples and screenshots. I am really looking forward to hearing your thoughts on this. Please feel free to share this idea with whomever you want to. If you think I should post this proposal somewhere else please say so. Kind regards, Simon Heckmann
Re: Proposal for a web application descriptor
There is a new version of the proposal out: http://www.simonheckmann.de/proposal/draft2 Am 29.04.2011 um 15:33 schrieb Simon Heckmann: Hello everyone, I have read a lot in the last month about the future of html and web applications and I am very impressed by the progress this makes. However, I have come across some thing that annoys me: Permissions. I know they are important and I know they are needed but currently I find this quite inconvenient. And with more and more permissions coming up this might get worse so I spent some time thinking about it. I have written a short document covering my proposal: www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or www.simonheckmann.de/proposal/ (HTML version). It should just take only a few minutes to read and includes examples and screenshots. I am really looking forward to hearing your thoughts on this. Please feel free to share this idea with whomever you want to. If you think I should post this proposal somewhere else please say so. Kind regards, Simon Heckmann
Re: Proposal for a web application descriptor
On Mon, 02 May 2011 10:04:58 +0200, Simon Heckmann si...@simonheckmann.de wrote: There is a new version of the proposal out: http://www.simonheckmann.de/proposal/draft2 You're thinking along very similar lines to the way we are thinking inside Opera about this problem, in terms of UI. However, I'm not so sure about having an object that authors can interact with for permissions. While the positive side is always good, letting malicious authors into this is known to be a major problem. Have you seen the work done by the Web Security Context group? http://www.w3.org/TR/wsc-ui/ cheers Chaals Am 29.04.2011 um 15:33 schrieb Simon Heckmann: Hello everyone, I have read a lot in the last month about the future of html and web applications and I am very impressed by the progress this makes. However, I have come across some thing that annoys me: Permissions. I know they are important and I know they are needed but currently I find this quite inconvenient. And with more and more permissions coming up this might get worse so I spent some time thinking about it. I have written a short document covering my proposal: www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or www.simonheckmann.de/proposal/ (HTML version). It should just take only a few minutes to read and includes examples and screenshots. I am really looking forward to hearing your thoughts on this. Please feel free to share this idea with whomever you want to. If you think I should post this proposal somewhere else please say so. Kind regards, Simon Heckmann -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Proposal for a web application descriptor
Am 02.05.2011 um 10:28 schrieb Charles McCathieNevile: On Mon, 02 May 2011 10:04:58 +0200, Simon Heckmann si...@simonheckmann.de wrote: There is a new version of the proposal out: http://www.simonheckmann.de/proposal/draft2 You're thinking along very similar lines to the way we are thinking inside Opera about this problem, in terms of UI. However, I'm not so sure about having an object that authors can interact with for permissions. While the positive side is always good, letting malicious authors into this is known to be a major problem. I though exactly the same: We would give the site a possibility to write to the UI of the browser. But I really like the benefit we get because the users know why they are granting each permission. The length of text could be limited and special characters could be stripped from the text. Maybe this way the mischief could be stemmed. If that is not what you mean, please elaborate your thoughts a little bit more. Have you seen the work done by the Web Security Context group? http://www.w3.org/TR/wsc-ui/ cheers Chaals Am 29.04.2011 um 15:33 schrieb Simon Heckmann: Hello everyone, I have read a lot in the last month about the future of html and web applications and I am very impressed by the progress this makes. However, I have come across some thing that annoys me: Permissions. I know they are important and I know they are needed but currently I find this quite inconvenient. And with more and more permissions coming up this might get worse so I spent some time thinking about it. I have written a short document covering my proposal: www.simonheckmann.de/download/Proposal.pdf (PDF, 3 pages, ~200KB) or www.simonheckmann.de/proposal/ (HTML version). It should just take only a few minutes to read and includes examples and screenshots. I am really looking forward to hearing your thoughts on this. Please feel free to share this idea with whomever you want to. If you think I should post this proposal somewhere else please say so. Kind regards, Simon Heckmann -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [IndexedDB] Closing on bug 9903 (collations)
On Sunday, 1 May 2011, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Apr 29, 2011 at 3:32 PM, Jonas Sicking jo...@sicking.cc wrote: I agree that we will eventually want to standardize the set of allowed collations. Similarly to how we'll want to standardize on one set of charset encodings supported. However I don't think we, in this spec community, have enough experience to come up with a good such set. So it's something that I think we should postpone for now. As I understand it there is work going on in this area in other groups, so hopefully we can lean on that work eventually. (Disclaimer: I never really tried to figure out how IndexedDB works, and I haven't seen the past discussion on this topic. However, I know a decent amount about database collations in practice from my work with MediaWiki, which included adding collation support to category pages last summer on a contract with Wikimedia. Maybe everything I'm saying has already been brought up before and/or everyone knows it and/or it's wrong, in which case I apologize in advance.) The Unicode Collation Algorithm is the standard here: http://www.unicode.org/reports/tr10/ It's pretty stable (I think), and out of the box it provides *vastly* better sorting than binary sort. Binary sort doesn't even work for English unless you normalize case and avoid punctuation marks, and it's basically useless for most non-English languages. Some type of UCA support in browsers would be the way to go here. UCA doesn't work perfectly for all locales, though, because different locales sort the same strings differently (French handling of accents, etc.). The standard database of locale-specific collations is CLDR: http://cldr.unicode.org/ CLDR tends to have several new releases per year. For instance, 1.9.1 was released this March, three versions were released last year, and five were released in 2009. Just looking at the release notes, it seems that most if not all of these releases update collation details. Because of how collations are actually used in databases, any change to the collation version will require rebuilding any index that uses that collation. I don't think it's a good idea for browsers to try packaging such rapidly-changing locale data. If everyone had Chrome's release and support schedule, it might work okay -- if you figured out a way to handle updates gracefully -- but in practice, authors deal with a wide range of browser ages. It's not good if every user has a different implementation of each collation. Nor if browsers just use a frozen and obsolescent collation version. I also don't know how realistic implementers would find it to ship collation support for every language CLDR supports -- the CLDR download is a few megabytes zipped, but I don't know how much of that browsers would need to ship to support all its tailorings. The general solution here would be to allow the creation of indexes based on a user-supplied function. I.e., the user-supplied function would (in SQL terms) take the row's data as input, and output some binary string. That string would be used as the key in the index, instead of any of the column values for the row. PostgreSQL allows this, or so I've heard. Then you could implement UCA (optionally with CLDR tailorings) or any other collation algorithm you liked in JavaScript. Of course, we can't expect authors to reimplement the UCA if they want to get decent sorting. It would make sense for browsers to expose some default sort functions, but I'm not familiar enough with UCA or CLDR to say which ones would be best in practice. It might make sense to expose some medium-level primitives that would allow authors to easily overlay tailoring on the basic UCA algorithm, or something. Or maybe it would really make sense to expose all of CLDR's tailored collations. I'm not familiar enough with the specs to say. But for the sake of flexibility, allowing indexes based on user-defined functions is the way to go. (They're useful for things other than collations, too.) The proposed ECMAScript LocaleInfo.Collator looks like it doesn't currently support this use-case, since it provides only sort functions and not sortkey generation functions: http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api If browsers do provide sortkey generation functions based on UCA, some versioning mechanism will need to be used, particularly if it supports tailored sortkeys. FWIW, MySQL provides some built-in collation support, but MediaWiki doesn't use it, because it supports too few languages and is too inflexible. MediaWiki's stock localization has 99% support for the 500 most-used messages in 175 different languages, and the couple dozen locales that MySQL supports aren't acceptable for us. Instead, we store everything with a binary collation, and are moving to a system where we compute the UCA sortkeys ourselves and put them in
Re: paste events and HTML support - interest in exposing a DOM tree?
On 05/02/2011 04:50 AM, ext Hallvord R. M. Steen wrote: event.clipboardData.getDocumentFragment() which would return a parsed and when applicable sanitized view of any markup the implementation supports from the clipboard. Rich text editors could now use normal DOM methods to dig through the contents and remove/add cruft as they wish on the returned document fragment, before doing an appendChild() and preventing the event's default action. For me, this problem looks very similar to the common pattern of getting HTML fragment out of XHR response. I think a general solution for parsing fragments would be better than this kind of special function only available through the clipboard. Mozilla has some good tools for this kind of problems: https://developer.mozilla.org/en/Code_snippets/HTML_to_DOM I would enjoy seeing a standard solution like this for the issue :) cheers, Benjamin
[widgets] Processing comments from 22-Mar-2011 LCWD of Widgets PC
Marcos, All - re processing comments submitted against the 22-Mar-2011 PC LCWD, FYI, below are the comments I noted. Are there any other comments, bugs, etc. that need to be considered? -AB Original Message Subject: [widgets] Reminder: Last Call Working Draft of Widgets PC; deadline May 1 Resent-Date:Fri, 22 Apr 2011 10:51:20 + Resent-From:public-webapps@w3.org Date: Fri, 22 Apr 2011 06:49:32 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org, Marcos Caceres marcoscace...@gmail.com Reminder: May 1 is the comment deadline for the 22-Mar-2011 LCWD of the Widget Packaging Configuration spec: http://www.w3.org/TR/2011/WD-widgets-20110322/ I recorded the following comments since that LCWD was published: = Charles McCathieNevile; 8-Apr-2011; localizingauthor http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0121.html = Addison Phillips; 30-Mar-2011; clarification on 9.1.3 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1076.html = Jonathan Rees; 23-Mar-2011; bug in example in step 6 of media type algorithm in WD-widgets-20110322 ? http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1042.html Marcos - are there any other LCWD comments? -ArtB
Re: [workers] Processing comments from 10-Mar-2011 LCWD
Hi Tab, All - can you Tab, or someone else, commit to processing the comments and bugs for the Workers LCWD? Given Hixie's bug list [1], perhaps we shouldn't wait for him. -Art [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0385.html On Apr/28/2011 1:35 PM, ext Arthur Barstow wrote: Hixie, All, April 21 was the comment deadline for the March 10 LCWD of the Web Workers spec [WW-LC]. Since that LC was published, I noted 2 set of comments and 2 new bugs: * Adrian Bateman; 9-Mar-2011 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0877.html * Travis Leithead; 20-Apr-2011 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0269.html * Bug-12067; Jonas Sicking; 14-Feb-2011 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067 * Bug-12340; Olli Pettay; 19-Mar-2011 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12340 Hixie - what normative changes have been made in the ED [WW-ED] (since the LC was published) that would affect an implementation based on the March 10 LC? The Process Document defines the requirements for processing LC comments [LC] and the WG's main requirement is to respond to all comments. It appears there is no agreed conclusion to the two comments nor to Bug-12067 and there were no responses to Bug-12340. -ArtB [WW-LC] http://www.w3.org/TR/2011/WD-workers-20110310/ [WW-ED] http://dev.w3.org/html5/workers/ [LC]http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Re: [widgets] Dig Sig spec
On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@nokia.com wrote: Marcos I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc this would take less time for you and be much clearer to all. I could only come up with 5... as I previously mentioned, the spec just contained a ton of redundancies (4 pages worth), but the conformance requirements are all pretty much the same. The draft is up at: http://dev.w3.org/2006/waf/widgets-digsig/ As I previously stated, the purpose of this fix up was to make concessions for WAC 1.0 runtimes, which use the default canonicalization algorithm of XML Dig Sig 1.1. Additional changes are based on working with various vendors who implemented the WAC 1 or are working on the WAC 2 specs (including the implementation that was done at Opera). 1. Validator and signers are now true [XMLDSIG11] implementations. No exceptions. This means that the test suite can be greatly reduced because everything is palmed off to [XMLDSIG11]. There is now a clear separation between a signer and validator, meaning that the implementation product is no longer needed. 2. Validators and signers now rely on [Signature Properties] for generation and validation of signature properties (as it should have been from the start). This removes a bunch of redundant text in the spec. The validation process is now written as an algorithm, as is the signing process. It makes it easy now to generate or validate a signature by simply following the steps. In the old spec, one had to jump all over the spec to check all sorts of things (e..g, Common Constraints for Signature Generation and Validation and the Requirements on Widget Signatures, both which are now folded into the appropriate algorithms). The spec now also links to the right places in [XMLDSIG11] and [Signature Properties]. 3. The specification now only RECOMMENDs algorithms, key lengths, and certificate formats. Validators are no longer forced fail on certain certificate formats or algorithm. The only exception is the minimum key lengths, which are still enforced during verification (impossible to test during signing, without verifying, so the requirement is kinda useless). 4. The specification strengthens the recommended key lengths to be a little bit stronger (buy a few more years). 5. The spec now only contains 3 conformance criteria. [ To digitally sign the contents of a widget package with an author signature, a signer MUST run the algorithm to generate a digital signature. To digitally sign the contents of a widget package with a distributor signature, a signer MUST run the algorithm to generate a digital signature. To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures. ] I think everyone will now find this new specification much easier to read, implement, and conform to without having in real impact on existing implementations. Kind regards, Marcos
Re: Proposal for a web application descriptor
On Mon, May 2, 2011 at 4:04 AM, Simon Heckmann si...@simonheckmann.de wrote: There is a new version of the proposal out: http://www.simonheckmann.de/proposal/draft2 This gets problematic when a browser has to ask for several permissions at the same time. Figure 1 illustrates this behaviour as seen in Google Chrome. Note that this can be improved without introducing new API. There aren't many permissions *yet*, so browsers havn't had much reason to put time into designing their permissions prompts to handling asking for multiple permissions simultaneously. In Chrome's cast, just aligning the allow/deny buttons would be a usability improvement, so when allow at the top is clicked, the next allow button is always directly under the mouse. See the attached image for another possible UI. (Implementing this securely would be a little tricky: the user might click allow all right as a third permission comes in. It would probably need to group permissions by when they're displayed, so if two or three permissions come in at once they'll have an allow-all button for the group, but if a fourth one comes along a second later it *won't* be merged into the existing allow-all button.) There are still possible arguments for allowing (but not requiring!) sites to batch their permissions all at once, but the current state of browsers doesn't seem like one of them--there are plenty of ways that might be improved first. Also, although I see how you're attempting to address the Android problem, the current mechanism is still much better. It's instantly obvious why a browser is asking allow this site to access your microphone? if I just clicked record a memo. Having a security question be so obvious is a huge win. Letting me make a security decision at the time it matters, when I'm naturally thinking about what it's asking about--instead of having to make them all in advance--is also a huge win. Adding a textual explanation for each permission only helps a little. -- Glenn Maynard attachment: allow.png
[indexeddb] result attribute for IDBRequest is set to undefined when calling IDBObjectStore.clear()
After calling the clear() method on IDBObjectStore, the result of the IDBRequest is set to undefined according to the steps for clearing an object store. However, the result property in IDBRequest says that the result value is undefined when the request results in an error: This is undefined when the request resulted in an error. In IE, we've been using undefined to signal properties that are not available to developers and null to signal unassigned values. It seems that null would be a better result value when the object store has been cleared. This would follow the same pattern we use in the deleteDatabase method where we return a null value for the result of the IDBRequest: If the steps above are successful, the implementation must set the result of the request to null and fire a success event at the request. What do you think? Israel
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, Apr 29, 2011 at 3:19 PM, Keean Schupke ke...@fry-it.com wrote: As long as we have a binary mode I am happy. Something I didn't think to mention: what exactly is binary mode for DOMStrings? I guess it means you encode as big-endian UTF-16, then sort bytewise? This is kind of evil, but it matches what sort() does, so I guess it should be the required behavior. (It's kind of evil because it doesn't match code-point order, unlike if you encoded as UTF-8. E.g., U+1 is encoded as 0xd800dc00 and U+E000 is 0xe000, so U+E000 sorts after U+1.) Perhaps this should be spelled out more clearly in the spec.
Re: paste events and HTML support - interest in exposing a DOM tree?
I see this as a possibly useful feature, even if it may not bring a
sensible difference for CKEditor.
In CKEditor we do clipboard data manipulation through the following steps:
1. Take the data string and send it to the browser, so it can clean up
things a bit (we set innerHTML for a div).
2. Take the innerHTML of that div.
3. Pass it through a custom string parser, which doesn't involve DOM
operations.
We do not use the DOM directly, because of its performance. Our custom
parser does a better job in that sense.
If we have the DOM from the clipboard directly, we would at least avoid
the above point 1, which could bring some performance benefits.
Thanks,
Fred
Frederico Caldeira Knabben
CEO, CKSource
http://cksource.com
Hallvord R. M. Steen wrote:
Hi,
a question related to the evolving draft on
http://www.w3.org/TR/clipboard-apis/ (which actually is slightly better
styled on http://dev.w3.org/2006/webapi/clipops/clipops.html - I should
figure out why ;-))
We want to enable some sort of access to HTML code if the user pastes
formatted text from an application that places HTML on the clipboard.
However, the browser will have to implement some security restrictions
(see relevant section of the spec - though it's just a draft), and in
some cases process the HTML to deal with embedded data when there are
sub-parts on the clipboard.
To handle both security algorithms and any embedded data, the browser
will probably need to parse the HTML. So actually, when you call
event.clipboardData.getData('text/html') the browser will get HTML from
the clipboard, parse it, do any work required by security and data
embeds rules on the DOM, and then serialize the code (possibly after
modifying the DOM) to pass it on to the script. Of course the script
will want to do its own processing, which will probably at some point
require parsing the code again..
So, to make things more efficient - would it be interesting to expose
the DOM tree from the browser's internal parsing? For example, we could
define
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the implementation supports from the clipboard. Rich text editors
could now use normal DOM methods to dig through the contents and
remove/add cruft as they wish on the returned document fragment, before
doing an appendChild() and preventing the event's default action.
Thoughts?
RE: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote: Excellent! I think that should mean that no changes are needed to the IndexedDB spec at all. I can't think of any instances where we use specific interface names while still accepting null values. / Jonas This implies the bug can be resolved, correct? Israel
Re: paste events and HTML support - interest in exposing a DOM tree?
Hallvord, Le 2 mai 2011 à 09:00, Hallvord R. M. Steen a écrit : I am not at all against your proposal but I tend to see two reasons against it: - I expect mostly the server to be providing the HTML, the javascript code does probably not need to process it further (they trust each other!) I don't really understand this comment. We're talking about HTML that comes from the clipboard, not from the server. I think this is not at all contradictory. In many of the scenarios I have working for, the content to be put on the clipboard would come from a luxury knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard. An offline HTML would also be an example of it. Hence... I would not really need a DOM representation. (however, I wonder if a timer is going to be honoured for such a query to be finished somehow). - I suppose the security processing may be done under an optimized processing which is not really necessarily DOM-exposed Maybe, maybe not. To sanitise something that will be inserted into a DOM structure, I would think the safest thing would be processing it according to DOM algorithms while sanitising too. Sure. paul
Re: [widgets] Dig Sig spec
It's pretty much impossible for me to figure out which things are new or which i've missed in previous rounds. (It's also possible that I didn't review this spec, in which case, I'm sorry.) I don't believe these comments significantly affect the document, i.e. they're mostly editorial, although some are technically errors which should definitely be fixed. http://dev.w3.org/2006/waf/widgets-digsig/ A widget package can be digitally signed by an author to produce a signature file that cryptographically includes all of the files of a widget package that are not i don't think includes is right, perhaps covers or attests. signature files (e.g., HTML files, CSS files, and JavaScript files). A user agent or other entity can use author signature to determine: use _an_ author As the following terms are used throughout this specification, they are gathered here for the readers convenience. reader's A file name is the name of a file contained in a widget package (excludes path information), as defined in the [Widgets Packaging] specification. probably s/excludes/excluding/ Set the a URI attribute for each ds:Reference to be the zip relative path that identifies a file inside the widget package. drop a Generate a identifier property in the manner specified in [Signature Properties]. an Serialized the signature as a [UTF-8] encoded [XML] document using the appropriate naming convention depending on its role: Serialize ? (present tense, action/command v. past tense) To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures. signature is misspelled terminate this algorithm and treat as an unsigned widget package: treat _it_ as... Check that signature has a ds:Reference for every file that is not a signature file. If every non-signature file is not included, then signature is in error. s/every/any/ s/not included/not listed/ If the role property is missing or or invalid, then signature is in error. s/or or/or/ If all signatures validated successfully, treat this as a signed widget package. s/validated/validate/ Search the root of the widget package for any file name that case-sesitively sensitively is misspelled This implies that, in order to verify a signature file, a user agent need needs A signature .. does not limit .. decompression and unpacking code used during signature extraction and verification. This doesn't seem to be a complete thought. A signature file can also be renamed, which can affect the order in which distributor signatures are processed. This could have been addressed by embedding the signature file name into the file, oh well :) Mechanisms to install new root certificates in a user agent need to be subject to security critical mechanisms. 'security critical mechanisms' doesn't sound right
Re: paste events and HTML support - interest in exposing a DOM tree?
On , Hallvord R. M. Steen hallv...@opera.com wrote:
Hi,
a question related to the evolving draft on
http://www.w3.org/TR/clipboard-apis/ (which actually is slightly better
styled on http://dev.w3.org/2006/webapi/clipops/clipops.html - I should
figure out why ;-))
We want to enable some sort of access to HTML code if the user pastes
formatted text from an application that places HTML on the clipboard.
However, the browser will have to implement some security restrictions
(see relevant section of the spec - though it's just a draft), and in some
cases process the HTML to deal with embedded data when there are sub-parts
on the clipboard.
To handle both security algorithms and any embedded data, the browser will
probably need to parse the HTML. So actually, when you call
event.clipboardData.getData('text/html') the browser will get HTML from
the clipboard, parse it, do any work required by security and data embeds
rules on the DOM, and then serialize the code (possibly after modifying
the DOM) to pass it on to the script. Of course the script will want to do
its own processing, which will probably at some point require parsing the
code again..
So, to make things more efficient - would it be interesting to expose the
DOM tree from the browser's internal parsing? For example, we could define
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the implementation supports from the clipboard. Rich text editors
could now use normal DOM methods to dig through the contents and
remove/add cruft as they wish on the returned document fragment, before
doing an appendChild() and preventing the event's default action.
Thoughts?
This is already covered by doing x=createElement;x.innerHTML=foo;traverse x
Regarding simplifying the pasted html to remove stuff that could be malicious,
consider a rogue app that injects a script in the clipboard and expects the
user to hit paste on his bank site. There is little the user agent can do but
to provide quick and easy methods to sanatize this. There is already the
toStaticHTML API that IE implements.
I would suggest supporting and implementing it. Or even add a sister property
of innerHTML, innerStaticHTML which would not return scripts or event handlers
on reading, and would parse out those when setting.
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Mon, May 2, 2011 at 1:49 PM, Israel Hilerio isra...@microsoft.com wrote: On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote: Excellent! I think that should mean that no changes are needed to the IndexedDB spec at all. I can't think of any instances where we use specific interface names while still accepting null values. / Jonas This implies the bug can be resolved, correct? Unless someone points out any specific functions in the API that needs clarification, I think we should close the bug yes. / Jonas
Re: Model-driven Views
Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. Re-rendering trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative-declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is fast by default. Libraries almost never do. -Our design is such that it fully delays all DOM work until the script event exits and then hands the instructions to the renderer as a batch. -UAs try to be lazy about doing work in order to only do expensive things minimally. This is the lazy nuclear option. All DOM work can be fully lazy. We're hopeful that there are big perf gains to be had here, but experimental implementations are the only way to prove this. -At minimum, the typical case can be assured to only incur one layout/style resolution. 6) Libraries can't hit the latency goals that we'd like to. -Libraries cannot render incrementally during page load. Leaving this to libraries will continue to put apps in the awkward position of *needing* to render on the server first so as to deliver a page that loads above the fold immediately and then precariously bootstrapping back into a proper dynamic separation of view model. -Wire-bytes are getting cheaper but latency isn't. Loading libraries is a bitter pill to swallow in order to create the basic abstractions you need to improve productivity and scale your application. [http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/] 7) Leaving DOM production to libraries worsens the tower of babel problem. -Most JS frameworks make an attempt to be in control of DOM production. The platform needs to be the cop and make the libraries play nice. For example, Angular would like to provide a development methodology but allow jQuery widgets to be used. Both (rightly so, lacking browser support) want to be in control. Chaos ensues. -We can spec the semantics, timing, and lifetime events of DOM production such that it opens the way for libraries to reliably plug in and be more confident that some other library won't break them. XBL is apropos for similar reasons. 8) Script has no ability to expand the declarative semantics of HTML -The operation of web apps is already
Re: Model-driven Views
On 5/2/11, Rafael Weinstein rafa...@google.com wrote:
Apologies. I feel like I have failed to properly contextualize this issue.
Let me back up and see if I can't help create a different frame of
reference. This email is already too long so I've avoided examples.
Please let me know what isn't apparent and I'll explain further.
1) Imperative templating (JSP, jQuery, Closure, a load of others) is
the problem. Declarative templating (Angular, Knockout, JSTemplate,
Spry) is the solution.
After reading your clarification, I am certainly confused about your
proposal, particularly of what exactly the problem is. I thought I
understood what you wanted, but now I'm sure I don't.
I rather like the proposal format of:
Problem: Need a way to do [blah].
[Approach X] works but has [disadvantage A].
[Approach Y] works but has [disadvantage B].
[Proposal] has none of [disadvantages {A, B}].
[Proposed fallback strategy] to use when [proposal] is unsupported.
[Failure] situation when [fallback strategy] is not used.
--
Garrett
