Re: [IME] Preparing some feedback
Hi Travis,
Thanks for the detailed spec and comments!
I'll read it through and will post comments on them.
On Thu, Apr 25, 2013 at 3:41 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
Kenji, et al.:
** **
We appreciate the work you’ve put into this IME API spec so far and hope
that this feedback will help further improve it! Jianfeng Lin, another
program manager from the IE team put the following feedback together, as
well as drafted the proposal, which I’ve uploaded to the mercurial server
for easy viewing at:
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html.
The proposal contains API designs that are the result of various feedback
from several different teams inside of Microsoft including use cases from
Microsoft Japan team, and designs from the folks who work on the in-box
Windows IMEs and the IME integration layer inside Internet Explorer.
** **
Thanks for taking the time to review,
-Travis
** **
Some Points of feedback:
** **
Composition Dictionary
** **
dictionary Composition {
readonly attribute Nodetext;
readonly attribute Range caret;
};
** **
We can see exposing IME clauses as child nodes of “text” node, and making
them real DOM nodes with styles being useful for a JS-based IME as the IME
needs to tell the web application how to render the composition, but if JS
IME is not a goal, is there any other scenarios that will benefit from
this? If not, how about a simple design that expose the text being composed
as DOMString?
** **
For “caret” attribute, if it’s for enabling JS-based IME, then exposing
the caret ranges of IME clauses is helpful, but if it’s not for JS IME, is
there any other usage? We understand that web applications want to know
about the whole string of the tentative composition, but we are not sure in
which case they want to know how the whole tentative composition string is
divided into several parts. Another issue is that the range type only tells
the start and end offsets of the composition from its immediate parent. Web
application usually wants to know the offset from the beginning of the text
field so that it could combine the composition alternate with the text
before it to create a full text string. But the beginning of the text field
can be up in the parent tree if it’s a contentEditable element and requires
JavaScript code to trace up in the parent tree to get the right offset. **
**
** **
So instead of a dictionary type for composition, we suggest this directly
under InputMethodContext interface. Please let us know if you have
scenarios that need to be the other way.
** **
readonly attribute DOMStringcompositionText;
readonly attribute unsigned long compositionStartOffset;
readonly attribute unsigned long compositionEndOffset;
** **
Beyond that, we also propose exposing the composition alternatives. For
example a search engine can use the current non-committed alternatives to
fine tune the real-time search suggestion list.
** **
sequence DOMString getCompositionAlternatives ();
** **
For the following in your proposal, is there any usage scenario besides
enabling IME on non-editable elements like canvas?
** **
attribute boolean enabled;
void setCaretRectangle (Node anchor, long x, long y, long w, long
h);
boolean open ();
** **
As we raised in the following discussion threads before, we don’t think
using canvas to create an editor is the right way to go. Please let’s
discuss about issues you are trying to solve and find out a better solution.
http://lists.w3.org/Archives/Public/public-html/2011Nov/0210
http://lists.w3.org/Archives/Public/public-html/2011Dec/0157.html
http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0029.html
** **
For the following function
** **
void setExclusionRectangle (Node anchor, long x, long y, long w,
long h);
** **
We recommend replacing with this
** **
ClientRect getCandidateWindowClientRect ();
** **
Because although setExclusionRectangle can ensure that the IME candidate
window doesn't overlap with some specific UI that the web application
doesn't want to be occluded (e.g. search suggestion list), it doesn’t seem
to be able to ensure that the two UIs layout in a desirable way. For
example, if the web application wants to render a search suggestion list
that docks below the IME candidate window and aligns nicely without gap, it
can't do so with setExclusionRectangle() because it doesn't know where is
the candidate window, how tall it is below the text field, and whether it
is horizontally shifted to follow the caret position. Therefore we are
proposing getCandidateWindowClientRect together with a group of CSS
properties to give more flexibility for
URL comparison
Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo
and http://url.spec.whatwg.org/
:local-link() seems like a special case API for doing URL comparison
within the context of selectors. It seems like a great feature, but
I'd like it if we could agree on common comparison rules so that when
we eventually introduce the JavaScript equivalent they're not wildly
divergent.
Requests I've heard before I looked at :local-link():
* Simple equality
* Ignore fragment
* Ignore fragment and query
* Compare query, but ignore order (e.g. ?xy will be identical to
?yx, which is normally not the case)
* Origin equality (ignores username/password/path/query/fragment)
* Further normalization (browsers don't normalize as much as they
could during parsing, but maybe this should be an operation to modify
the URL object rather than a comparison option)
:local-link() seems to ask for: Ignore fragment and query and only
look at a subset of path segments. However, :local-link() also ignores
port/scheme which is not typical. We try to keep everything
origin-scoped (ignoring username/password probably makes sense).
Furthermore, :local-link() ignores a final empty path segment, which
seems to mimic some popular server architectures (although those
ignore most empty path segments, not just the final), but does not
match URL architecture.
For JavaScript I think the basic API will have to be something like:
url.equals(url2, {query:ignore-order})
url.equals(url2, {query:ignore-order, upto:fragment}) // ignores fragment
url.equals(url2, {upto:path}) // compares everything before path,
including username/password
url.origin == url2.origin // ignores username/password
url.equals(url2, {pathSegments:2}) // implies ignoring query/fragment
or some such. Better ideas more than welcome.
--
http://annevankesteren.nl/
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Wed, Apr 24, 2013 at 2:35 PM, Tobie Langel to...@w3.org wrote: On Wednesday, April 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen wrote: Hi there, CSS Device Adaptation should hopefully be enabled on all browsers (desktop and mobile) unlike the viewport meta tag, which cannot be enabled on desktop browsers easily as many desktop sites actually comes with a viewport meta tag which is ignored. Having that not being ignored breaks the sites. *Sigh* MS already enabled a subset of the CSS Device Adaptation spec in IE10 desktop. I support adding some CSSOM API's for CSS Device Adaptation, but I would not do so for the viewport meta tag, which has its share of issues. Understandably given the above. Outside of the IE10 implementation mentioned above, have other implementors committed to implement the CSS part of CSS Device Adaptation? We are looking at enabling it for Chromium, no ETA on that though, as there seems to be some interest from Android and Opera as well. I would also like the CSS Device Adaptation, orientation lock and Fullscreen to integrate. Especially it would be nice to click on an element in portrait and have it go fullscreen in landscape mode and lock, all with a nice animation. Agreed. These should work together as much as possible. Thanks for your comments. --tobie -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆
Why not be multiEntry and array keyPath togather?
createIndexhttp://www.w3.org/TR/IndexedDB/#widl-IDBObjectStore-createIndex-IDBIndex-DOMString-name-any-keyPath-IDBIndexParameters-optionalParametersAPI specification state that If keyPath is and Array and the multiEntry property in the optionalParameters is true, then a DOMException of type NotSupportedError must be thrown. I believe NotSupportedError is unnecessary. multiEntry is no different than non-multiEntry index value, except the reference value is repeated. This specification limit generalizes usage of composite index for key joining algorithm. Google appengine datastore also have have multiEntry (ListPropertyhttps://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#ListProperty). It has no special different in indexing, other than limiting number of entrieshttps://groups.google.com/forum/?fromgroups=#!topic/google-appengine/1fTct9AO1MYand warning for possibility of explosive index. Composite index with multiEntry is very useful, like modelling graph data and many-to-many relationship. Currently query on such model are limited to single index. It is also very unlikely that web developer will use excessive indexing. I propose NotSupportedError left out of specification. Best regards, Kyaw
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
On 19.04.13 00:01, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Thu, 18 Apr 2013 19:19:17 +0300, Paul Bakaus pbak...@zynga.com wrote: Hi Jonas, Thanks for this I feel this is heading somewhere, finally! I still need to work on submitting my full feedback, but I'd like to mention this: Why did nobody so far in this thread include real world use cases? We submitted a few (they are not completely fleshed out but they are actual things we do) in the related thread http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0949.html Thanks both! I will dig through the links. Might be worth to collect them all into a list that's easily accessible so we can base any proposal or update to proposals on the UC's and validate against them. For a highly complex topic like this in particular, I would think that collecting a large number of user use cases, not only requirements, and furthermore finding the lowest common denominator based on them, would prove very helpful, even if it's just about validation and making people understand your lengthy proposal. I.e. a news reader that needs to sync content, but has an offline UI. Do you have a list collected somewhere? There are also use cases in the discussions of hosted apps in the SysApps WG - they are essentially working on the same problem. cheers Chaals Thanks! Paul On 26.03.13 16:02, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about fixing appcache. Last year mozilla got a few people together mostly with the goal of understanding what the actual problems were. The notes from that meeting are available at [1]. Those discussions, and a few followup ones, has made it clear that there were a few big ticket items that we needed to fix: * The fact that master entries are automatically added to the cache works very poorly for a lot of developers. * Once a website is cached the user will only see the new version on second load, even if the user is online. This is good for performance but is a behavior many websites aren't willing to live with. * You have to tweak a comment of the manifest in order to trigger an update-check of the cached resources. * We need an escape hatch for people running into missing features in the appcache. I.e. a way for websites to use script to complement the set of behaviors supported by the appcache spec. * The fact that FALLBACK combined the hit network first, fall back to a cached resource and allow a cached resource to handle requests to a whole URL space behaviors is problematic since many times you want one and not the other. * People want to use appcache not just to make offline apps possible, but also make online apps fast. * There isn't enough ability to control the appcache through javascript. There are certainly other things that people have mentioned, but the above have been a reoccurring theme. Feel free to comment here if you have other issues with the current appcache, but it might be worth doing that as separate threads. I believe that some of these problems stem from a relatively small set of design problems: The appcache appears to be aimed at too simple applications. It works fine if the website you want to cache consists of a small set of static resources and otherwise only use features like IndexedDB or localStorage to manage dynamic data. But once an application uses server-side processing to dynamically generate resources based on query parameters or other parts of the URL, then it requires that you change the way that your application works. Another design aspect that appears to be causing problem is that appcache is optimized too heavily for minimizing the amount of typing that the author had to do. It attempts to help the author too much, for example by automatically adding master entries that link to an appcache but aren't enumerated in it. Or automatically adding the handler URLs from the FALLBACK section to the set of URLs to be automatically downloaded. The result is that the appcache contains too much magic. In theory an author can just type very little and the appcache will automatically do the right thing. However this magic is making it too hard for authors to understand what's going on. The result is that people don't use the appcache even if they might have needed to type very little to get it working. Implementations certainly hasn't helped here either, by not exposing the behind-the-scenes logic through debugging and developer tools. The fact that the appcache is aimed at simple applications is generally a good thing given that it's the first version. However the desire to make applications available offline, as well as make them faster when the user is online, has been so
Re: Fixing appcache: a proposal to get us started
On 2013-03-27 01:20, Jonas Sicking wrote:
On Tue, Mar 26, 2013 at 1:48 AM, James Graham jgra...@opera.com wrote:
On 03/26/2013 08:02 AM, Jonas Sicking wrote:
Another feature that we are proposing is to drop the current
manifest format and instead use a JSON based one. The most simple
reason for this is that we noticed that the information we need to
express quickly became complex enough that using a format with simple
parsing rules was beneficial.
A format based on extending the current appcache format would be no
problem for a UA to parse. However the complexity that we need to
express resulted in something that's too hard for a human to manually
write, or for a human to understand when looking at somebody else's
manifest in order to learn.
The simple parsing rules for JSON seemed like a better fit. It also
provides more of an opportunity to extend the format in the future.
JSON also has advantages when it comes to creating APIs exposed to
webpages for interacting with appcaches. More about this below.
Some slightly trivial feedback: I am worried about using a format with no
support for comments. I agree that some hypothetical JSON+comments format
would be a good fit, but without the ability to document complex rulesets,
it seems like we are going to create a maintenance nightmare.
I completely agree. I feel like we're stuck between a rock and a hard
place here.
On one hand we need something that supports comments. JSON only
supports comments using ugly hacks like:
{
//: Remember to update this as needed,
version: 2,
//: Need nav.css for sidebar,
cache: [index.html, index.css, nav.css]
}
On the other hand, using something other than JSON means that we loose
the ability to use existing tool chains for processing the manifest.
I'm not so worried about the UA having to write new code in order to
implement the AppCache feature itself. I'm more concerned that
serverside code that wants to process the manifest can't use a normal
JSON parser, and that client-side code that wants to load a manifest
can't use things like xhr.responseType=json.
I really don't know which downside is worse.
I definitely wish that JSON supported comments, but that doesn't seem
likely to ever happen :(
...
Well, there is a format with good server and client support that allows
comments. It's called XML.
Best regards, Julian
Proposal for a filesystem API
Hi WebApps!
There has been a lot of controversy about implementing a file system API in
other browsers. Firefox and IE already support storing files in IndexedDB,
but it seems that web developers need something simpler in some cases and
there's also the filesystem URL scheme that is not covered by files in
IndexedDB.
This new proposal is heavily based on Apple's minimal filesystem API
proposal [1], on Mozilla's DeviceStorage API 2 [2] and on Mozilla's current
FileHandle API [3]. It is only designed for the use case of sandboxed local
file storage.
In Firefox, the FileHandle API provides the ability to write to a file, as
well as the locking mechanisms needed to allow writing safely. The
FileHandle interface is currently supported in IndexedDB and it is also
planned for DeviceStorage API. However, the new proposal for the file
system API uses a modified version of the FileHandle API. The FileHandle
interface acts exactly like LockedFile in the current FileHandle API. I.e.
it represents an opened file and it automatically closes if you stop
posting requests against it (like transactions in IDB except it doesn't
provide any rollback functionality, i.e. only Isolation of the ACID).
There's a documentation for the current FileHandle API [4], which contains
detailed description of the LockedFile interface (that now becomes the new
FileHandle interface).
Here's the proposed file system API:
Getting the root directory:
enum PersistenceType { temporary, permanent };
dictionary FilesystemParameters
{
PersistenceType storage;
};
partial interface Navigator {
Directory getSandboxedFilesystem(optional FilesystemParameters
parameters);
};
The Directory interface:
enum FileOpenMode { read, write, append };
interface Directory {
readonly attribute DOMString name;
// Asynchronously returns boolean true or false to indicate success.
Futureboolean
create(DOMString name, optional Blob blob);
// Asynchronously returns the newly created Directory.
FutureDirectory
makeDirectory(DOMString name);
// Asynchronously returns a File or Directory. If the entry is a File
// then get() is a shortcut for openForReading().getFile()
FutureFile or Directory
get(DOMString name);
// Deletes a file or directory; Asynchronously returns boolean true or
false
// to indicate success.
Futureboolean
remove(DOMString name);
// Atomically renames a file or directory; Asynchronously returns boolean
// true or false to indicate success.
Futureboolean
rename(DOMString oldName, DOMString newName);
// alternative method for rename():
// Atomically moves or renames a file or directory; Asynchronously returns
// boolean true or false to indicate success.
Futureboolean
moveTo((DOMString or File or Directory) entry, DOMString newName,
optional Directory newParentDirectory);
// TODO: maybe add copyTo() method
// Asynchronously returns a FileHandle; error if called on a Directory.
// If a File is passed, it must be a descendant of this directory.
FutureFileHandle
openRead((DOMString or File) file);
// Asynchronously returns a FileHandleWritable;
// error if called on a Directory.
// If a File is passed, it must be a descendant of this directory.
FutureFileHandleWritable
openWrite((DOMString or File) file);
// Asynchronously returns a FileHandleWritable;
// error if called on a Directory.
// If a File is passed, it must be a descendant of this directory.
FutureFileHandleWritable
openAppend((DOMString or File) file);
// alternative method for openRead(), openWrite(), openAppend():
Future(FileHandle or FileHandleWritable)
open((DOMString or File) file, optional FileOpenMode mode);
// TODO: Solve futures way of doing a cursor-style API
// Asynchronously returns File or Directory objects.
CursorFutureFile or Directory
enumerateShallow(); // or readEntries();
// Asynchronously returns File objects
CursorFutureFile
enumerateDeep(); // or readEntriesRecursively();
};
The FileHandle/FileHandleWritable interface, representing a file open in
read, write or append mode.
dictionary MetadataParameters
{
boolean size = false;
boolean lastModified = false;
};
interface FileHandle
{
// read or write or append
readonly attribute FileOpenMode mode;
readonly attribute boolean active;
// Offset in the file. This value is changed automatically after every
read
// and every write. Reads and writes always start at the location.
// null means end-of-file
attribute any location;
// Upon success, you receive a read-only snapshot of the file's content
in
// the form of a File instance (that can be used anywhere a Blob is
accepted,
// like FileReader, XMLHttpRequest, IndexedDB, etc).
FutureFile getFile();
// Asynchronously returns an ArrayBuffer of the given size. The operation
// starts at the location. Moving the location by the number of bytes
read.
ProgressFutureArrayBuffer
readAsArrayBuffer(unsigned
Re: Why not be multiEntry and array keyPath togather?
Some of us were just discussing this yesterday - it does seem reasonable for the next iteration. Can you file a bug at https://www.w3.org/ (product: WebAppsWG, component: Indexed Database API) to track this? Including scenario details such as you've done above would be great. On Thu, Apr 25, 2013 at 7:09 AM, Kyaw Tun kyaw...@yathit.com wrote: createIndexhttp://www.w3.org/TR/IndexedDB/#widl-IDBObjectStore-createIndex-IDBIndex-DOMString-name-any-keyPath-IDBIndexParameters-optionalParametersAPI specification state that If keyPath is and Array and the multiEntry property in the optionalParameters is true, then a DOMException of type NotSupportedError must be thrown. I believe NotSupportedError is unnecessary. multiEntry is no different than non-multiEntry index value, except the reference value is repeated. This specification limit generalizes usage of composite index for key joining algorithm. Google appengine datastore also have have multiEntry (ListPropertyhttps://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#ListProperty). It has no special different in indexing, other than limiting number of entrieshttps://groups.google.com/forum/?fromgroups=#!topic/google-appengine/1fTct9AO1MYand warning for possibility of explosive index. Composite index with multiEntry is very useful, like modelling graph data and many-to-many relationship. Currently query on such model are limited to single index. It is also very unlikely that web developer will use excessive indexing. I propose NotSupportedError left out of specification. Best regards, Kyaw
Re: URL comparison
On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo
and http://url.spec.whatwg.org/
:local-link() seems like a special case API for doing URL comparison
within the context of selectors. It seems like a great feature, but
I'd like it if we could agree on common comparison rules so that when
we eventually introduce the JavaScript equivalent they're not wildly
divergent.
My plan is to lean *entirely* on your URL spec for all parsing,
terminology, and equality notions. The faster you can get these
things written, the faster I can edit Selectors to depend on them. ^_^
Requests I've heard before I looked at :local-link():
* Simple equality
* Ignore fragment
* Ignore fragment and query
* Compare query, but ignore order (e.g. ?xy will be identical to
?yx, which is normally not the case)
* Origin equality (ignores username/password/path/query/fragment)
* Further normalization (browsers don't normalize as much as they
could during parsing, but maybe this should be an operation to modify
the URL object rather than a comparison option)
:local-link() seems to ask for: Ignore fragment and query and only
look at a subset of path segments. However, :local-link() also ignores
port/scheme which is not typical. We try to keep everything
origin-scoped (ignoring username/password probably makes sense).
Yes.
Furthermore, :local-link() ignores a final empty path segment, which
seems to mimic some popular server architectures (although those
ignore most empty path segments, not just the final), but does not
match URL architecture.
Yeah, upon further discussion with you and Simon, I agree we shouldn't
do this. The big convincer for me was Simon pointing out that /foo
and /foo/ have different behavior wrt relative links, and Anne
pointing out that the URL spec still makes example.com and
example.com/ identical.
For JavaScript I think the basic API will have to be something like:
url.equals(url2, {query:ignore-order})
url.equals(url2, {query:ignore-order, upto:fragment}) // ignores fragment
url.equals(url2, {upto:path}) // compares everything before path,
including username/password
url.origin == url2.origin // ignores username/password
url.equals(url2, {pathSegments:2}) // implies ignoring query/fragment
or some such. Better ideas more than welcome.
Looks pretty reasonable. Only problem I have is that your upto key
implicitly orders the url components, when there are times I would
want to ignore parts out-of-order.
For example, sometimes the query is just used for incidental
information, and changing it doesn't actually result in a different
page. So, you'd like to ignore it when comparing, but pay attention
to everything else.
So, perhaps in addition to upto, an ignore key that takes a string
or array of strings naming components that should be ignored?
This way, :local-link(n) would be equivalent to:
linkurl.equals(docurl, {pathSegments:n, ignore:userinfo})
:local-link would be equivalent to:
linkurl.equals(docurl, {upto:fragment}) (Or {ignore:fragment})
~TJ
RE: URL comparison
Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * Further normalization (browsers don't normalize as much as they could during parsing, but maybe this should be an operation to modify the URL object rather than a comparison option) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? [1]http://dev.w3.org/csswg/selectors/#local-pseudo However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? -s
Re: URL comparison
On Thu, Apr 25, 2013 at 11:41 AM, s...@cateches.is wrote: Requests I've heard before I looked at :local-link(): * Simple equality * Ignore fragment * Ignore fragment and query * Further normalization (browsers don't normalize as much as they could during parsing, but maybe this should be an operation to modify the URL object rather than a comparison option) What about links that point to a null URL with a hash? ie a href=#back-to-top Obviously this is a local link, but it doesn't really fit into the host/path/query segmentation that's defined with the :local-link([0|1|2...]) definition[1]. Perhaps a :local-link(hash) keyword would be appropriate so that we could select links within the page? That's what :local-link (without the ()) is for - it selects links within the same page. That is, links where the url is identical, ignoring the hash. However, :local-link() also ignores port/scheme which is not typical. Isn't it perfectly reasonable to expect that a different scheme/port is running an entirely different application? Yes, which is why Anne says that we should include port/scheme in the comparison. ~TJ
[Shadow DOM] Simplifying level 1 of Shadow DOM
(Resent from correct email address) Hi, First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose that we simplify the feature for 1.0, and defer some complexity to the next level. I think we can address most of the use cases of shadow DOM while seriously reducing the complexity of the feature by making one change: What if we only allowed one insertion point in the shadow DOM? Having just 1 insertion point would let us push (most? all?) of this complexity off to level 2: * distribution, getDistributedNodes(), etc. * selector fragments matching criteria * /select/ combinator * content select * shadow ? * reprojection Notably, I don't think insertion point(s) get used (much or at all) in WebKit's internal shadow trees, so I don't think all of the above complexity is worth it right now. Baby Steps.[1] Ted 1. The lost HTML design principle: http://www.w3.org/html/wg/wiki/DesignPrinciplesReview#Baby_Steps
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
Hello, This is an interesting suggestion. Here are some notes: Reducing to one insertion point doesn't, in itself, eliminate distribution, getDistributedNodes(), etc content select I assume you mean one insertion point that always selects everything. Also, fwiw, shadow we use for inheritance. And * reprojection we use for composition. We in the above refers to my team which is using ShadowDOM (in native and polyfill forms) to make interesting custom elements. On Thu, Apr 25, 2013 at 2:42 PM, Edward O'Connor eocon...@apple.com wrote: (Resent from correct email address) Hi, First off, thanks to Dimitri and others for all the great work on Shadow DOM and the other pieces of Web Components. While I'm very enthusiastic about Shadow DOM in the abstract, I think things have gotten really complex, and I'd like to seriously propose that we simplify the feature for 1.0, and defer some complexity to the next level. I think we can address most of the use cases of shadow DOM while seriously reducing the complexity of the feature by making one change: What if we only allowed one insertion point in the shadow DOM? Having just 1 insertion point would let us push (most? all?) of this complexity off to level 2: * distribution, getDistributedNodes(), etc. * selector fragments matching criteria * /select/ combinator * content select * shadow ? * reprojection Notably, I don't think insertion point(s) get used (much or at all) in WebKit's internal shadow trees, so I don't think all of the above complexity is worth it right now. Baby Steps.[1] Ted 1. The lost HTML design principle: http://www.w3.org/html/wg/wiki/DesignPrinciplesReview#Baby_Steps
[Bug 21833] New: Under read* chaining during load event loadends should be suppressed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21833
Bug ID: 21833
Summary: Under read* chaining during load event loadends should
be suppressed
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: File API
Assignee: a...@mozilla.com
Reporter: a...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org
In code of the sort:
reader.readAsText(file);
reader.onload = function(){reader.readAsText(file2););
The loadend event should not fire.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 21836] New: Remove NotSupportedError on creating index for multiEntry index with array keyPath
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21836 Bug ID: 21836 Summary: Remove NotSupportedError on creating index for multiEntry index with array keyPath Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: kyaw...@yathit.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org In creating index, the specification state that: If keyPath is and Array and the multiEntry property in the optionalParameters is true, then a DOMException of type NotSupportedError must be thrown. However it is unnecessary. multiEntry is no different than non-multiEntry index value, except the reference value is repeated. This specification limit generalizes usage of composite index for key joining algorithm. Composite index with multiEntry is very useful, like modelling graph data and many-to-many relationship. Currently query on such model are limited to single index. It is also very unlikely that web developer will use excessive indexing. Discussion on: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0379.html -- You are receiving this mail because: You are on the CC list for the bug.
