Re: [editing] CommandQuery Object and Event
On Jun 5, 2014, at 10:42 AM, Ben Peters wrote: >> From: Ryosuke Niwa [mailto:rn...@apple.com] >> >> Can this be an attribute on elements instead? Otherwise, browsers would >> have to repeatedly call these functions to update edit menu, etc... > > This may be an issue, I agree. But since it's dynamic and changes every time > the selection/caret moves, would an attribute really help us save > computation? Maybe we should be able to get the status of several commands at > once with the event? Something like this (just thinking out loud here)? We should avoid running JS to update the browser UI since that will make the timing of events dispatch dependent on specific implementations. I'm fine with adding some interface objects that needs to be called upon selection change, etc... If keep updating the states is a concern, we can expose a list of states that UA care about somewhere so that the scripts can avoid updating other states - R. Niwa
[Bug 26001] New: [Shadow]: The type of arguments of ShadowRoot.ElementFromPoint must be `double` instead of `float`
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26001 Bug ID: 26001 Summary: [Shadow]: The type of arguments of ShadowRoot.ElementFromPoint must be `double` instead of `float` Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 WebIDL checker found this minor issue. That said: > unless there are specific reasons to use a 32 bit floating point type, > specifications SHOULD use double rather than float. Document.ElementFromPoint(..) also uses `double`. See http://dev.w3.org/csswg/cssom-view/#dom-document-elementfrompoint -- You are receiving this mail because: You are on the CC list for the bug.
Re: IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
You are correct:
A case of BROKEN debugging tool (Chrome Web Console in Chrome 35) and a
typo that produced no error (I had e.target.cursor instead of
e.target.result)
If the debugger is broken (I realize it's been fixed now) it makes it hard
to tell weather the bug is in my code or in the implementation.
Given our prior conversation on this list resulted in some useful feedback,
according to you, I figured that you wanted to continue getting feedback on
this list. I guess the distinction to make is between reports of potential
bugs (which should go to chromium-html5 unless they are cross browser in
which case I'd post them here, right?) and API design issues (spec issues)
which is what my other post from a couple weeks ago was about. If it's the
latter then I'll post here, right? If the former I'll post to
chromium-html5. Since I only use Chrome in my current work, I'll probably
never bother verifying any bugs I find on other browsers, so I'll direct
them to chromium-html5.
Anything else?
Thanks for coding the test, and will post more DEBUGGER BUGS on
chromium-html5 that impact debug-ability of IDB apps. There are at least a
couple more.
On Thu, Jun 5, 2014 at 2:53 PM, Joshua Bell wrote:
> The spec has no such limitation, implicit or explicit. I put this together:
>
> http://pastebin.com/0GLPxekE
>
> In Chrome 35, at least, I had no problems indexing 100,000 tags. (It's a
> bit slow, though, so the pastebin code has only 10,000 by default)
>
> You mention 50 items, which just happens to be how many records are shown
> on one page of Chrome's IDB inspector in dev tools. And paging in the
> inspector was recently broken (known bug, fix just landed:
> http://crbug.com/379483). Are you sure you're not just seeing that?
>
> If you're seeing this consistently across browsers, my guess is that
> there's a subtle bug in your code (assuming we've ruled out a double-secret
> limit imposed by the cabal of browser implementors...) This isn't a support
> forum, so you may want to take the issue elsewhere - the chromium-html5 is
> one such forum I lurk on.
>
> If you're not seeing this across browsers, then this is definitely not the
> right forum. As always, please try and reduce any issue to a minimal test
> case; it's helpful both to understand what assumptions you may be making
> (i.e. you mention a cursor; is that a critical part of your repro or is a
> simple count() enough?) and for implementors to track down actual bugs. If
> you do find browser bugs, please report them - crbug.com,
> bugzilla.mozilla.org, etc.
>
>
>
> On Thu, Jun 5, 2014 at 2:15 PM, marc fawzi wrote:
>
>> Hi Joshua, IDB folks,
>>
>> I was about to wrap up work on a small app that uses IDB but to my
>> absolute surprise it looks that the number of indexed values in a
>> MultiEntry index is limited to 50. Maybe it's not meant to contain an
>> infinite number but 50 seems small and arbitrary. Why not 4096?
>> Performance? If so, why is it NOT mentioned in any of the IDB docs
>> published by the browser vendors?
>>
>> Following from my previous example (posted to this list), "tags" is a
>> multiEntry index defined like so:
>>
>> objectStore.createIndex("tags", "tags", {unique: false, multiEntry: true})
>>
>> When I put in say 3000 tags as follows:
>>
>> var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc:
>> etc})
>>
>> Only the first 50 elements of myTagsArray show up in the Keys column
>> within the Chrome Web Console (under Resources-->IndexedDB--->tags) and
>> it's not a display issue only: The cursor (shown below) cannot find any
>> value beyond the initial 50 values in myTagsArray. This is despite the
>> cursor.value.tags containing all 100+ values.
>>
>> var range = IDBKeyRange.only(tags[0], "prev")
>>
>> var cursor = index.openCursor(range)
>>
>> Is this by design? Anyway to get around it (or do it differently) ? and
>> why is the limit of 50 on indexed values not mentioned in any of the docs?
>>
>> I bet I'm missing something... because I can't think of why someone would
>> pick the number 50.
>>
>> Thanks,
>>
>> Marc
>>
>>
>>
>>
>
>
Re: IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
The spec has no such limitation, implicit or explicit. I put this together:
http://pastebin.com/0GLPxekE
In Chrome 35, at least, I had no problems indexing 100,000 tags. (It's a
bit slow, though, so the pastebin code has only 10,000 by default)
You mention 50 items, which just happens to be how many records are shown
on one page of Chrome's IDB inspector in dev tools. And paging in the
inspector was recently broken (known bug, fix just landed:
http://crbug.com/379483). Are you sure you're not just seeing that?
If you're seeing this consistently across browsers, my guess is that
there's a subtle bug in your code (assuming we've ruled out a double-secret
limit imposed by the cabal of browser implementors...) This isn't a support
forum, so you may want to take the issue elsewhere - the chromium-html5 is
one such forum I lurk on.
If you're not seeing this across browsers, then this is definitely not the
right forum. As always, please try and reduce any issue to a minimal test
case; it's helpful both to understand what assumptions you may be making
(i.e. you mention a cursor; is that a critical part of your repro or is a
simple count() enough?) and for implementors to track down actual bugs. If
you do find browser bugs, please report them - crbug.com,
bugzilla.mozilla.org, etc.
On Thu, Jun 5, 2014 at 2:15 PM, marc fawzi wrote:
> Hi Joshua, IDB folks,
>
> I was about to wrap up work on a small app that uses IDB but to my
> absolute surprise it looks that the number of indexed values in a
> MultiEntry index is limited to 50. Maybe it's not meant to contain an
> infinite number but 50 seems small and arbitrary. Why not 4096?
> Performance? If so, why is it NOT mentioned in any of the IDB docs
> published by the browser vendors?
>
> Following from my previous example (posted to this list), "tags" is a
> multiEntry index defined like so:
>
> objectStore.createIndex("tags", "tags", {unique: false, multiEntry: true})
>
> When I put in say 3000 tags as follows:
>
> var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc:
> etc})
>
> Only the first 50 elements of myTagsArray show up in the Keys column
> within the Chrome Web Console (under Resources-->IndexedDB--->tags) and
> it's not a display issue only: The cursor (shown below) cannot find any
> value beyond the initial 50 values in myTagsArray. This is despite the
> cursor.value.tags containing all 100+ values.
>
> var range = IDBKeyRange.only(tags[0], "prev")
>
> var cursor = index.openCursor(range)
>
> Is this by design? Anyway to get around it (or do it differently) ? and
> why is the limit of 50 on indexed values not mentioned in any of the docs?
>
> I bet I'm missing something... because I can't think of why someone would
> pick the number 50.
>
> Thanks,
>
> Marc
>
>
>
>
IndexedDB: MultiEntry index limited to 50 indexed values? Ouch.
Hi Joshua, IDB folks,
I was about to wrap up work on a small app that uses IDB but to my absolute
surprise it looks that the number of indexed values in a MultiEntry index
is limited to 50. Maybe it's not meant to contain an infinite number but 50
seems small and arbitrary. Why not 4096? Performance? If so, why is it NOT
mentioned in any of the IDB docs published by the browser vendors?
Following from my previous example (posted to this list), "tags" is a
multiEntry index defined like so:
objectStore.createIndex("tags", "tags", {unique: false, multiEntry: true})
When I put in say 3000 tags as follows:
var req = objectStore.add({tags: myTagsArray, someKey: someValue, etc: etc})
Only the first 50 elements of myTagsArray show up in the Keys column within
the Chrome Web Console (under Resources-->IndexedDB--->tags) and it's not a
display issue only: The cursor (shown below) cannot find any value beyond
the initial 50 values in myTagsArray. This is despite the cursor.value.tags
containing all 100+ values.
var range = IDBKeyRange.only(tags[0], "prev")
var cursor = index.openCursor(range)
Is this by design? Anyway to get around it (or do it differently) ? and why
is the limit of 50 on indexed values not mentioned in any of the docs?
I bet I'm missing something... because I can't think of why someone would
pick the number 50.
Thanks,
Marc
Re: Indexed DB Transactions vs. Microtasks
On Thu, 5 Jun 2014, Joshua Bell wrote:
>
> For case 2, it looks like implementations differ on whether microtasks
> are run as part of the event dispatch. This seems to be outside the
> domain of the IDB spec itself, somewhere between DOM and ES. Anyone want
> to offer an interpretation?
Event dispatch (specifically, the handling of "onsuccess", as opposed to
addEventListener('success') which is similar but defined in other specs)
is something that HTML tries to define. Assuming IndexDB defers to HTML's
definition of "event handler IDL attribute", then you go through the
"event handler processing algorithm", which calls "jump to a code
entry-point" which calls "clean up after running a callback" which calls
"perform a microtask checkpoint" which, once ES and HTML have been made to
play nice, invokes the promise callbacks, all before the task that fired
the event handler has returned to the event loop. And once it does return
to the event loop, the next major thing _it_ does is "perform a microtask
checkpoint" anyway.
HTH.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Indexed DB Transactions vs. Microtasks
Playing with Promise wrappers for IDB, the intersection of IDBTransaction's
|active| state and microtask execution came up. Here are a couple of
interesting cases:
case 1:
var tx;
Promise.resolve().then(function() {
tx = db.transaction(storeName);
// tx should be active here...
}).then(function() {
// is tx active here?
});
case 2:
var tx = db.transaction(storeName);
var request = tx.objectStore(storeName).get(0);
request.onsuccess = function() {
// tx should be active here...
Promise.resolve().then(function() {
// is tx active here?
});
};
In Chrome 35, the answers are "no", "no". This is because it was a
non-conforming Promise implementation, with the Promise callbacks not run
as microtasks. This was addressed in 36, so please disregard this behavior.
In Chrome 36, the answers are "yes", "yes".
In Firefox 29, the answers are "yes", "no".
For case 1, ISTM that "yes" matches the IDB spec, since control has not
returned to the event loop while the microtasks are running.
Implementations appear to agree.
For case 2, it looks like implementations differ on whether microtasks are
run as part of the event dispatch. This seems to be outside the domain of
the IDB spec itself, somewhere between DOM and ES. Anyone want to offer an
interpretation?
Re: [editing] CommandQuery Object and Event
On 6/5/14 1:42 PM, Ben Peters wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Can this be an attribute on elements instead? Otherwise, browsers would
have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
Based on a quick scan of the IndieUI WG participant list ([IndieUI]), it
appears Ted and James Craig would be the "best" suspects. That group's
mail list is
RE: [editing] CommandQuery Object and Event
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>
> Can this be an attribute on elements instead? Otherwise, browsers would
> have to repeatedly call these functions to update edit menu, etc...
This may be an issue, I agree. But since it's dynamic and changes every time
the selection/caret moves, would an attribute really help us save computation?
Maybe we should be able to get the status of several commands at once with the
event? Something like this (just thinking out loud here)?
Document.queryCommands('bold', 'italic', 'underline', 'undo')
> Also, we should talk with people working on Indie UI
> (http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
> similar to the one they're trying to solve.
Absolutely! This has been in the back of my mind for a while. Do you know what
would be the best way to involve them? Are some of them in both working groups?
[Bug 25994] New: invalid extended attribute list syntax
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25994 Bug ID: 25994 Summary: invalid extended attribute list syntax Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: gl...@skynav.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org The extended attribute list syntax used in the File API does not adhere to current WebIDL specification syntax. In particular, production 64 of the syntax [1] must consist of a comma separated list of ExtendedAttribute items. [1] http://heycam.github.io/webidl/#proddef-ExtendedAttributeList In order to fix this, please make the following changes: (1) on definition of Blob interface, change [Exposed=Window,Worker][Constructor, Constructor(sequence<(ArrayBuffer or ArrayBufferView or Blob or DOMString)> blobParts, optional BlobPropertyBag options)] to [Constructor, Constructor(sequence<(ArrayBuffer or ArrayBufferView or Blob or DOMString)> blobParts, optional BlobPropertyBag options), Exposed=Window,Worker] (2) on definition of File interface, change [Exposed=Window,Worker][Constructor(sequence<(Blob or DOMString or ArrayBufferView or ArrayBuffer)> fileBits, [EnsureUTF16] DOMString fileName, optional FilePropertyBag options)] to [Constructor(sequence<(Blob or DOMString or ArrayBufferView or ArrayBuffer)> fileBits, [EnsureUTF16] DOMString fileName, optional FilePropertyBag options), Exposed=Window,Worker] (3) on definition of FileReader interface, change [Exposed=Window,Worker][Constructor] to [Constructor, Exposed=Window,Worker] (4) on definition of FileReaderSync interface, change [Exposed=Worker][Constructor] to [Constructor, Exposed=Worker] Note that I have also reordered the Exposed extended attribute above to improve readability (given that it can contain a ',' as well). -- You are receiving this mail because: You are on the CC list for the bug.
Re: [HTML Imports] What is the imagined work flow?
Dimitri, Thank you for your excellent reply. As you mention the dependency resolution properties are also available in ES6 modules. I feel there is a case to be made for ES6 modules being used for any resource type loading. e.g. https://github.com/briandipalma/spa-2014-app/blob/master/src/SpaApplicationElement.js This Custom Element is able to load in it's dependent styling and template information. Albeit it requires extensions to the ES6 module loader they are not exceptionally complex. My preference for a ES6 module solution is biased by the fact I spend most of my time in JS code. I can imagine people who want to drop in some some broadly reusable functionality (social widgets etc) would prefer a HTML Import. If it's just a matter of adding a tag and either works then I'd question the use of two broadly similar specs. It might be easier to add native CSS and HTML loading to ES6 modules then to add HTMLImports to the platform. B. On Fri, May 23, 2014 at 6:42 PM, Dimitri Glazkov wrote: > Brian, > > I believe Scott enumerated all these in his initial reply, but here's > my take (I wrote parts of this in another email, my apologies to that > email's recipient for repeating myself :) > > HTML Imports are primarily about dependency resolution. They allow the > web developer to think locally in terms of their dependencies. Then, > the underlying machinery builds a global dependency graph and turns it > into a tree to ensure consistent processing order. > > Scripts in the imports are evaluated in this order. In addition, HTML > Imports load/apply styles to the document in the same order, which > enables a much saner way to reason about components and their effects. > > For example, in Jan Miksovsky's presentation at SFHTML5 event, he shows > something very interesting > (https://www.youtube.com/watch?feature=player_detailpage&v=mN7IAaRdi_k#t=8608). > > He pastes > > href="http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html";> > > in a jsbin and instantly gets his custom element work (modulo the > platform.js polyfill, which will eventually not be necessary). This is > super important. A typical way to do this prior to imports is: > > 1) Add the
[Bug 25987] New: Blob URL parsing / fetching model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987 Bug ID: 25987 Summary: Blob URL parsing / fetching model Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: gl...@zewt.org, jo...@sicking.cc, public-webapps@w3.org Depends on: 25914 Blocks: 24338 Given http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0683.html we might need to revisit our strategy. It seems we've already given the URL parser access to the global environment so it can reach the blob URL store. However, the scope of the blob URL store also encompasses global environments that can be reached solely through document.domain and so not all of them are same-origin. So I guess in addition a same-origin check is in order. I guess we should do the same-origin check in the URL parser so it's deterministic. And then fetching a URL which has an associated object will just never fail. Does that make sense? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25915] Cross-origin requests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915 Anne changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Anne --- This still seems wrong. :-( I think basically you do not want to say anything about cross-origin URLs and let that part of the security model be handled by Fetch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25914] No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 Anne changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Anne --- This is wrong. The URL parser is http://url.spec.whatwg.org/ That returns you components you can operate on. 'scheme data' seems to be the identifier you want. Or maybe 'scheme data' + "?" + 'query'. -- You are receiving this mail because: You are on the CC list for the bug.
Re: contentEditable and forms (was: contentEditable=minimal)
On May 27, 2014, at 2:56 AM, Robin Berjon wrote: > On 27/05/2014 09:19 , Piotr Koszuliński wrote: >> Yes, it should be possible to disable whichever feature you don't need. >> In some cases you don't need lists (because e.g. you're editing a text >> that will become a content of a paragraph). And in some cases you don't >> want bold/italic because your use case requires only structured HTML. So >> being able to handle such commands is a one thing. But first of all >> there should be no assumption that a user needs these buttons, because a >> browser just don't know about that. If I think that users need toolbar, >> I can render a custom one. > > Much agreed. The browser should not show any markup/styling affordance for > cE=minimal. > >> There's one more assumption that makes editing on mobile devices >> (especially low-res devices) very hard. It's that if user focuses >> editable, then he/she wants to type, so native keyboard should pop out. >> Very often it's true, but in some cases user may want to select some >> text and using toolbar apply styles or lists, etc. And when the keyboard >> is visible there's very little space to do that. If there was any API to >> control whether keyboard is visible, then we could achieve much better UX. > > There are quite a few things from forms that I think could usefully become > available in an editing context. We could benefit from having the inputmode > attribute be allowed on any editable piece of text. For the specific use case > you cite, an additional keyword of "none" might make sense too. > > It possibly wouldn't hurt to have the placeholder attribute be available on > all editable content, too. I'm less sure about the validation attributes > (except perhaps required) but why not. > > Obviously validation attributes only make sense if the editable content can > contribute to forms. But it would make a lot of sense that it could. Today > you have to resort to ugly hacks in which you somehow copy over the edited > content into a textarea. That's pretty daft: in most use cases you're going > to be submitting the content. There was a discussion about participating in the form submission in general back in Feb: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html > There are several ways in which we could handle this. One is to have any > element with cE=minimal contribute to the form data set (when inside a form, > or possibly when using the form attribute if someone remembers what the use > case for that thing was). That's interesting, but I get a sense that it > conflates two features. Another approach is to add a "submittable" attribute > that can make the innerHTML of any element contribute to the form data set. > > Thoughts? I think we should come up with a generic form participation mechanism that could be used for cE=minimal. - R. Niwa
Re: [editing] CommandQuery Object and Event
Can this be an attribute on elements instead? Otherwise, browsers would have
to repeatedly call these functions to update edit menu, etc...
Also, we should talk with people working on Indie UI
(http://www.w3.org/WAI/IndieUI/). The problem we're solving here is very
similar to the one they're trying to solve.
On Jun 4, 2014, at 11:31 AM, Ben Peters wrote:
> There has been some conversation about browser UI for Commands with
> ContentEdtiable=minimal. Some people seem to believe that UI should not be
> displayed because it may not be relevant. One way to solve this is to have an
> event that would allow script to tell the browser what is relevant. Today,
> there are several ways to ask the browser if a given command is
> enabled/relevant. This includes queryCommandEnabled, queryCommandSupported,
> and QueryCommandValue. However, the site is not able to influence the return
> value of these events. In order to give more power to browsers, frameworks,
> and sites, it seems to make sense to allow these values to be modified.
> Therefore I propose a new method:
>
> document.queryCommand()
>
> which returns a new read-only object (called CommandQuery for now):
>
> CommandQuery
> {
> Boolean isSupportedByUA;
> Boolean isSupported;
> Boolean isEnabled;
> Object currentValue;
> }
>
> By default, this object will match the browser's support for this command in
> the current context. However, before it returns, a CommandQuery event will
> fire with a read/write CommandQuery object. If a framework or site wishes to
> indicate different values for the command state, it can do so in that event.
>
> CommandQueryEvent: Event {
> {
> CommandQuery commandQuery;
> }
>
> In this way, a framework can enable commands that a browser does not natively
> support. Further, a browser could fire CommandQueryEvents to determine the
> correct toolbar buttons to display. Thoughts?
>
> Ben
>
Re: contentEditable=minimal
On May 23, 2014, at 1:37 PM, Robin Berjon wrote: > On 23/05/2014 21:32 , Jonas Sicking wrote: >> On Fri, May 23, 2014 at 4:43 AM, Robin Berjon wrote: >>> On 23/05/2014 12:28 , Jonas Sicking wrote: And on mobile autocorrect of misspelled words is common, though that can probably be handled by moving the selection to the misspelled word and then writing the fixed word. >>> >>> Autocorrect should be handled like composition. Composition is pretty much >>> what happens whenever you type some stuff and some other stuff comes out. >>> (Technical definition.) >> >> I sadly don't think it's that simple. When compositing chinese >> characters, or characters like ü, an underline should be rendered >> during the composition and then removed once a character (or set of >> characters) is selected. This underline should not appear when typing >> on a mobile keyword, even if it supports autocorrect. >> >> It's not clear to me if the difference is just one of styling, or if >> there are semantic differences as well. > > Semantically, autocorrect and compositing really are the same thing. They are not. Word substations and input method compositions are semantically different operations. > How that gets rendered may be another story, but I'll point out that there > are mobile UIs in which the word being typed is underlined. Just because they're treated the same way in one platform doesn't allow us to treat them same in all platforms. It's crucial for editors on the Web to be able to use the same UI for on the platforms that do differentiate the two. > Note that if there is a degree of refinement such that we may want to make it > possible for authors to style compositing-for-characters and > compositing-for-autocorrect, then that ought to go into the styling system. In older versions of Windows, for example, the browser itself can't figure out what kind of style is used by IME. Korean and Japanese IME on Windows, for example, use bolded lines and dotted lines for opposite purposes. And we get bug reports saying that WebKit's rendering for Korean IME is incorrect because we decided to follow Japanese IME's convention. > We /could/ consider adding a field to compositing events that would capture > some form of ontology of input systems. But I think that's sort of > far-fetched and we can get by with the above. (And yes, I'm using "ontology" > on purpose. It wouldn't look good :) In my opinion, it's a requirement that input methods work and look native on editors that use this new API. IME is not a nice-to-have feature. It's a feature required for billions of people to type any text. >> My assertion is that we don't want to use compositing events when >> typing on a keyboard which has autocorrect. (This might be a wrong >> assertion in which case none of this matters). Rather than composition >> events we fire events like: >> >> insert 'c' >> insert 'a' >> insert 'g' >> selection moved to start at index 0 and end at index 3 >> insert 'cat' >> insert ' ' >> >> However we've previously said that pages should be able to cancel or >> adjust selection moves. The question is what happens if the page >> changes the selection when autocorrect attempts to select the word to >> be fixed. > > Gotcha, and indeed you are correct. If autocorrect were implemented as a > change of the selection followed by an insert of the correction, the > application could unwillingly interfere with the selection and cause mayhem. > But even if that weren't the case this would feel pretty hacky. Maybe you are > thinking of this because on recent Androids when you autocorrect there's an > animation that more or less makes it look like that's what's going on? > > Honestly, I really think that compositing events are the right abstraction > here. We can get finicky on style tweaks, but they work for all compositing > systems I can think of admittedly not *that* many but still quite a few). > They would even work for T9! I strongly disagree. - R. Niwa
Re: contentEditable=minimal
On May 27, 2014, at 1:33 AM, Robin Berjon wrote: > On 27/05/2014 01:47 , Ben Peters wrote: >>> -Original Message- From: Robin Berjon >>> On 26/05/2014 05:43 , Norbert Lindenberg wrote: Were any speakers of bidirectional languages in the room when this was discussed? >>> >>> I don't know what languages the others speak. That said, my >>> recollection was that this was presented along the lines of "we've >>> had regular requests to support selecting text in geometric rather >>> than logical orders". >> >> I have also heard these requests from the bi-directional experts here >> at Microsoft. A single, unbroken selection is what we're told users >> want, and multi-selection makes this possible. > > Thinking about this a little bit more: I don't imagine that the Selection API > should prescribe the UI that browsers choose to support in order to select > bidi text, on the contrary they should be allowed to innovate, experiment, > follow various platform conventions, etc. But if we don't support multi-range > selection, then only one model is possible which precludes unbroken > selections. > > I think that this strongly pushes in the direction of supporting multiple > ranges. I agree visual selection of bidirectional text is a problem worth solving but I don't think adding a generic multi-range selection support to the degree Gecko does is the right solution. For starters, most of author scripts completely ignore all but the first range, and applying editing operations to a multi-range selection is a nightmare. - R. Niwa
