Re: File API: Blob URL origin

[Anne van Kesteren]

On Tue, Jul 1, 2014 at 1:13 AM, Glenn Maynard  wrote:
> Why would the identifier not just be the blob URL itself?  The spec
> currently makes the identifier just the scheme data, which seems much more
> complex than it needs to be.  revokeObjectURL should simply be "Remove the
> entry from the Blob URL Store for URL."  If we want to allow revoking URLs
> that have a fragment attached it'd still need to strip it off; Firefox does
> this, but Chrome doesn't.

That works for me. That way we can make this a more generic store if
god forbid we get more of these schemes.


> Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg.
> "Blob:..." won't revoke the URL, or uppercasing the hostname portion in
> Chrome.  Using the whole URL as the identifier makes this easy to do.

Ew, but okay I guess.


> "Subsequent attempts to dereference url must return a network error" should
> be removed.  That should already be the consequence of unregistering the
> URL, so this is a redundant requirement.

Agreed.


-- 
http://annevankesteren.nl/

Re: [editing] Leading with ContentEditable=Minimal

[Johannes Wilm]

On Tue, Jul 1, 2014 at 4:39 AM, Ryosuke Niwa  wrote:

> On Jun 30, 2014, at 1:43 PM, Johannes Wilm 
> wrote:
>
> On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa  wrote:
>
> 

>
>>
>>- Web-based DTP application: The app can creates a document that
>>contains pagination, columns, and a complex illustrations.  It needs to 
>> let
>>users edit any text that appears in the document.  Each editable text 
>> needs
>>to be accessible, and styles applied to text need to be backed by the
>>application's internal model of the document.
>>
>> Yes, but wouldn't this require some fragmentation logic? To create
> something like what Quark Xpress was in the 1990s, I think you'd need CSS
> Regions or equivalent. It seems as if that would be a little outside of the
> scope of the caret moving logic, or how do you mean? I would find it great
> if this ever happens, but as I understand it the whole fragmentation debate
> was left aside for a while.
>
>
> CSS regions is still shipped in iOS/OS X Safari, and I don't expect it to
> go away anytime soon.  CSS columns support is still in Blink as well.
>  Furthermore, I don't think CSS WG is halting the work on fragmentations
> either.  We should still keep it as a use case for the new editing API.  In
> addition, I would suggest that you go talk with people in CSS WG and add
> your use case.
>

Yes, I am aware of that. I spent a year creating a CSS Regions based book
layout engine ( http://fiduswriter.github.io/pagination.js/ ) , so I am
absolutely interested in fragmentation coming back one day. In the meantime
I have created an ad-hoc solution using CSS columns (
http://fiduswriter.github.io/simplePagination.js/simplePagination.html )

The main difference is that the CSS fragmentation based version allows to
combine it with contenteditable (text flowing from page to page while
editing/writing it). Using Javascript/CSS multicolumns to create the same
design means cutting up the DOM, so it has to be done after the text is
written. We switched to this second approach when it became clear that CSS
Regions would be removed from Chrome.

The way we handle it is to let the user write the text in one large page
with the footnotes off to the right. When the user hits CTRL+P, the current
contents of the edited doc are copied, the original contents is hidden and
the copied version is cut up into individual pages. By the time the user
gets to the print preview, page numbers, headers, table of contents,
footnotes, etc. have all been put in place. Fragmentation would be great to
have, but for now I would already sleep much better if we would have a more
solid selection/caret-moving base to build upon.



>
>>- Semantic HTML WYSIWYG editor for a blogging platform: The editor
>>needs to able to add both semantic and visual annotation to the document 
>> as
>>it will be published as a blog.  Headings are to be marked up with h1. h2,
>>etc... and each acronyms, abbreviations, and so forth are marked up with
>>respective HTML elements.  However, the editor also supports visual
>>annotations such as bolding, italicizing, and enlarging text, each of 
>> which
>>will be interpreted by the editor to respective underlying semantics in
>>HTML.
>>
>> Yes, and in order to keep things consistent he may want to disallow
> certain types of styling. A few years ago it was common to see people with
> Joomla sites who just pasted the text into the editor after copying it from
> a word processor. Each blog post therefore ended up having very different
> styling.
>
>
> Could you elaborate more on what kind of inline styling you're thinking
> of?  And how and why you want to allow/restrict certain styles?  You're
> providing us of really important information here, and I really appreciate
> if you could give us more information here :)
>

For example a blog may decide not to allow any inline-css styling. And to
emphasize words they may only want to allow bold and italics, but not
underline and not a combination of italics and bold on the same word.

Of course visually this may be achievable using a lot of !important
statements in a general css file for the page. But the contents will turn
messy and if users copy  from a social media site to a word processor to a
blog, and from there to another blog and then into their html-based email
and then into another blog... things will end in disaster for certain at
some point.

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org

Re: [editing] Leading with ContentEditable=Minimal

[Ryosuke Niwa]

On Jun 30, 2014, at 1:43 PM, Johannes Wilm  wrote:
> On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa  wrote:
>  
> 
> On Jun 26, 2014, at 3:24 PM, Olivier F  wrote:
>  
>> I agree these all seem the same. Here are a few other use cases I can think 
>> of:
>> 
>> * Create a web-based structured content editor, where the allowable DOM 
>> elements and/or classes in the content are pre-defined.
> 
> Could you elaborate on the use case of making such an editor?  e.g. allowing 
> only certain types of styling in comments.
> 
> We do that in Fidus Writer.  Part of the point is to keep the structure of 
> the document semantically defined. Users can't change font sizes of 
> individual words, etc. . This is because one of the main tasks of scientific 
> journal editors who currently receive drafts in Word or Libreoffice format 
> have to undo all the manual styling the writers have added in order to get 
> everything to look in a similar way. we simply take those styling 
> possibilities away so that we can define the entire design through one 
> stylesheet as well as easily convert to other formats, such as LaTex or an 
> Epub, and be sure that we cover all formatting tags that were used.

Interesting. That's a very good use case indeed.

> 
>> * A complete book/whatever editor, which can contain areas of non-editable 
>> content, nested editable content, etc... See fiduswriter.org, and what 
>> CKEditor are doing with widgets.
> 
> Could you elaborate on how non-editable content appears/used inside an 
> editable content?
> 
> We also do that - for example in the case of formulas. Generally the text is 
> editable near-Wysiwyg style. But when it comes to formulas, we let the user 
> enter them in Latex format and display the result using mathjax. Each formula 
> object within the text is a noneditable island. If the user clicks on it with 
> the mouse, he can change the formula.
> 
> Another example are figures: We want them to always be block elements and to 
> have exactly one caption without styling. They are therefore non-editable 
> islands and if the user clicks on them he can change the figure's display and 
> the caption text.

Ditto.

> 
>> * Browser-based code editor. Currently CodeMirror and others go through 
>> amazing lengths to provide something that looks and behaves like a desktop 
>> code editor.
>> * Browser based "word art" generator where end-user types some text and it 
>> renders in 3D along a curve and in rainbow colors on a .
> 
> These are great use cases.
> 
> I'd throw in two more:
> Web-based DTP application: The app can creates a document that contains 
> pagination, columns, and a complex illustrations.  It needs to let users edit 
> any text that appears in the document.  Each editable text needs to be 
> accessible, and styles applied to text need to be backed by the application's 
> internal model of the document.
> Yes, but wouldn't this require some fragmentation logic? To create something 
> like what Quark Xpress was in the 1990s, I think you'd need CSS Regions or 
> equivalent. It seems as if that would be a little outside of the scope of the 
> caret moving logic, or how do you mean? I would find it great if this ever 
> happens, but as I understand it the whole fragmentation debate was left aside 
> for a while.

CSS regions is still shipped in iOS/OS X Safari, and I don't expect it to go 
away anytime soon.  CSS columns support is still in Blink as well.  
Furthermore, I don't think CSS WG is halting the work on fragmentations either. 
 We should still keep it as a use case for the new editing API.  In addition, I 
would suggest that you go talk with people in CSS WG and add your use case.

> Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to 
> able to add both semantic and visual annotation to the document as it will be 
> published as a blog.  Headings are to be marked up with h1. h2, etc... and 
> each acronyms, abbreviations, and so forth are marked up with respective HTML 
> elements.  However, the editor also supports visual annotations such as 
> bolding, italicizing, and enlarging text, each of which will be interpreted 
> by the editor to respective underlying semantics in HTML.
> Yes, and in order to keep things consistent he may want to disallow certain 
> types of styling. A few years ago it was common to see people with Joomla 
> sites who just pasted the text into the editor after copying it from a word 
> processor. Each blog post therefore ended up having very different styling.

Could you elaborate more on what kind of inline styling you're thinking of?  
And how and why you want to allow/restrict certain styles?  You're providing us 
of really important information here, and I really appreciate if you could give 
us more information here :)

- R. Niwa

Re: Fallout of non-encapsulated shadow trees

[Maciej Stachowiak]

> On May 15, 2014, at 6:17 AM, Anne van Kesteren  wrote:
> 
> I'm still trying to grasp the philosophy behind shadow trees.
> Sometimes it's explained as "exposing the primitives" but the more I
> learn (rather slowly, this time at BlinkOn) the more it looks like a
> bunch of new primitives.
> 
> We cannot explain  still, but since we allow going inside the
> shadow tree we now see the need for a composed tree walker (a way to
> iterate over a tree including its non-encapsulated interleaved shadow
> trees). In addition we see the need for a composed range of sorts, so
> selection across boundaries makes sense. Neither of these are really
> needed to explain bits of the existing platform.

I agree with the need for encapsulation in Web Components and have been arguing 
for it for a long time. Currently, despite agreement dating back several years, 
it doesn’t even offer a mode with better encapsulation. Now that the 
non-encapsulation version has shipped in Chrome, it may be hard to change other 
than by renaming everything.

Web Components as currently designed cannot explain the behavior of any 
built-in elements (except maybe those which can be explained with CSS alone).

Regards,
Maciej

Re: Fallout of non-encapsulated shadow trees

[Ryosuke Niwa]

On May 15, 2014, at 6:17 AM, Anne van Kesteren  wrote:

> I'm still trying to grasp the philosophy behind shadow trees.
> Sometimes it's explained as "exposing the primitives" but the more I
> learn (rather slowly, this time at BlinkOn) the more it looks like a
> bunch of new primitives.
> 
> We cannot explain  still, but since we allow going inside the
> shadow tree we now see the need for a composed tree walker (a way to
> iterate over a tree including its non-encapsulated interleaved shadow
> trees). In addition we see the need for a composed range of sorts, so
> selection across boundaries makes sense. Neither of these are really
> needed to explain bits of the existing platform.

I would really like get a grasp on everyone's perspective here as well (please 
be as concise as possible).

I feel that a lot of contention about shadow DOM and other aspects of Web 
Components comes from the fact everyone has his/her own definition of Web 
Components.

It would be of great use to state clearly what problem each party is 
trying/hoping to resolve with Web Components, or more specifically with shadow 
DOM in this thread.

- R. Niwa

Re: [HTML Imports] What is the imagined work flow?

[Ryosuke Niwa]

I've talked to a few of my colleagues here at Apple who work on JavaScriptCore 
but they don't seem to think that
the ES6 modules is the right mechanism to import arbitrary sub resource since 
the semantics of loading CSS, HTML, etc...
depends on the context whereas ES6 module has exactly one purpose: importing a 
ES6 module.

We do share the same sentiment that it's more natural to trigger resource loads 
within the script.
For example, I could imagine adding a new syntax for loading an arbitrary sub 
resource dependency.

We also agree that authors should to be able to use the single dependency graph 
shared with ES6 modules:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715

- R. Niwa

On Jun 5, 2014, at 6:07 AM, Brian Di Palma  wrote:

> 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 

Re: Should / Can an EventHandler throw a stack overflow exception?

[Mark S. Miller]

I would like to see us take a principled stance on resource exhaustion
errors in ES7. This includes both stack and heap, and both space and time.
For example, the browser behavior on terminating a turn that takes too long
and proceeding silently to the next turn leaves arbitrary invariants
broken. Other resource exhaustion conditions cause the same problems.

See 



On Mon, Jun 30, 2014 at 1:59 PM, Anne van Kesteren  wrote:

> On Mon, Jun 30, 2014 at 6:01 PM, Boris Zbarsky  wrote:
> > On 6/30/14, 4:40 AM, Anne van Kesteren wrote:
> >> Are stack overflow exceptions even a thing per standards?
> >
> > No.
> >
> > However, they come up pretty regularly in practice.  In fact, some sites
> > depend on them for proper functioning.  :(
>
> Paging Allen. If defining this needs to start anywhere, it would
> probably be ECMAScript.
>
>
> --
> http://annevankesteren.nl/
> ___
> es-discuss mailing list
> es-disc...@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM

Re: [editing] CommandQuery Object and Event

[Ryosuke Niwa]

On Jun 9, 2014, at 4:21 PM, Piotr Koszuliński  
wrote:

> Responding to browser UI is one thing and I totally agree with the need for 
> user intent events. If user shakes iPhone editor should be notified that user 
> wanted to undo. But I does not tie this to commands at this point at all. 
> Events exist to notify app that something is going to happen. The default 
> behaviour of what happens may be hidden behind a command, method or engine 
> internals, but that's a separate topic.
> 
> As for CommandQuery Event, I commented it in [2] and indirectly in my 
> previous email. In my opinion it tries to hide symptoms of contenteditable's 
> sickness rather than cure it. "Existing commands break my app or are useless 
> for it, so let me allow to disable them". 
> 
> 1. Most editors will disable as much of them as possible (I wonder what about 
> paste/cut/copy) to hide native UI which may conflict with custom UI (e.g. 
> overlap it) or simply to block undesired, unclear feature.
> 2. If developer is forced to leave any of commands enabled (e.g. to not lose 
> clipboard support), he/she risks that native UI will be displayed and will 
> break his app.
> 3. If developer wants to enable some option (e.g. smart quotes) he/she risks 
> that native UI will break his app or that user will be able to disable such 
> option when should not be able to do that.
> 4. Some of these issues may be solved by special commands blocking native UI 
> without disabling specific commands.
> 5. In many scenarios native UI is useless, because it cannot be extended and 
> redesigned (new buttons, new types of UI elements), so it only satisfies 
> small subset of use cases.
> 6. Even if e.g. mobile Safari displays all buttons necessary for developer's 
> use case, if any other browser does not do that, then developer has to 
> override everything anyway. Without interoperability 
> 7. A11y is not a reason to make browser handle all the UI. If ARIA's roles 
> are not sufficient or some API is missing, then they should be added, not 
> native UI extended. As I said, most of (advanced) editors will need to hide 
> native UI, so if providing a11y using HTML and JavaScript is not possible on 
> some platform (mobile?), then this problem will need to be solved anyway.
> 8. What if some command should have configurable behaviour? For example quote 
> characters used by smart quotes feature might be configurable (language 
> dependent?). What API allows this? Assuming that we've got two commands - 
> disableSmartQuotes and enableSmartQuotes, which of them I have to disable to 
> get rid of them from the UI? Sure there's a solution for all that, but 
> extending commands APIs indefinitely will lead to even bigger mess than now. 
> And having bazillion options in tight high-level API, without providing any 
> primitives is a bad design choice.
> 
> None of these points is a deal breaker when considered separately. But all of 
> them (plus many we don't yet see) combined together makes the situation look 
> terrible. Commands, related APIs, native UI are useless or problematic for 
> editors (meaning real editors, not these adding contenteditable=true to a 
> div) and still will be useless. Commands API might look extensible, because 
> it uses strings as commands identifiers, but that's a very high-level native 
> API, so if any feature is not included (like setting characters used by smart 
> quotes), everything has to be implemented in JS from scratch. Native UI is 
> inextensible and uncontrollable and still will be (command events cover only 
> execution logic).
> 
> Someone said that contenteditable=true tries to be an entire WYSIWYG editor 
> (a poor one actually) at once and that that's bad. I couldn't agree more. Is 
> adding new options to tame the contenteditable=true going to fix this? No. It 
> will make the situation slightly more acceptable, but contenteditable=true is 
> still terminally ill, because it still pretends to be an editor

I think you're presuming that we're going to keep all the features enabled by 
default, and let authors disable them later.  That would indeed cause a problem 
for editors such as code editor or semantic editor that need to have a more 
fine control over what goes into the editor.

On the other hand, features such as smart quotes, autocorrections, 
spellchecking are platform-wide features (on OS X and iOS).  Not having such 
features inside an editable region in a browser would only confuse users.  So 
editors that don't need to have full control over the content should be able to 
get these features for free, and editors that need more granular control should 
be able to opt-in.

For the latter case, we could come up with a set of categories for common 
editing features new platforms and browsers tend to introduce/support, and 
provide an API for each category of editing operations so that authors could 
intercept them as needed (e.g. a pair of replacement events for smart quotes) 
without having

Re: DIsjoint ranges (was: contentEditable=minimal)

[Ryosuke Niwa]

On Jun 23, 2014, at 8:23 AM, Robin Berjon  wrote:

> On 06/06/2014 18:52 , Ryosuke Niwa wrote:
>> On Jun 6, 2014, at 6:40 AM, Robin Berjon  wrote:
>>> On 05/06/2014 09:02 , Ryosuke Niwa wrote:
 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.
>>> 
>>> I'd be interested to hear how you propose to solve it in another
>>> manner. Also note that that's not the only use case, there are
>>> other possibilities for disjoint selections, e.g. a table
>>> (naturally) or an editable surface with a non-editable island
>>> inside.
>> 
>> Supporting disjoint range is probably necessary but adding the
>> ability to manipulate each range separately seems excessive because
>> that'll lead to selections with overlapping ranges, ranges in
>> completely different locations that are not visually disjoint, etc...
>> We might need to do something like exposing readonly multi-range
>> selection.
> 
> Readonly multiranges may be an option, but I can think of some issues (which 
> perhaps we can address).
> 
> Several people have mentioned the use case in which a script wants to observe 
> selection changes in order to ensure that selections conform to certain 
> constraints. Consider the following:
> 
>  abc 2 defg
>  ABC 1 defg
> 
> Let's imagine that the script wishes to constrain the selection to only that 
> second line, that the user clicks at 1 and drags towards 2. You'd want the 
> script to constrain the range such that it just selects "ABC ". If you only 
> cancel the selection change, presumably it doesn't select anything at all 
> here (and I'm also presuming that with such a gesture you don't get a 
> selection change event for each character in between the two drag points — 
> that would be a lot).
> 
> What is weird in this scenario is that so long as the text is unidirectional 
> you can manipulate the range, but the second "B" is a character in a 
> different direction you can't. (And then again, *only* in browsers that 
> support visually continuous selection across bidi boundaries — in others it 
> would still work.)
> 
> I don't think that this variability is good; it is likely to surprise 
> developers.
> 
> Another issue is that in some cases I believe that *visually* disjoint 
> selections are the right thing to do. If you have an editing host that 
> contains a readonly island, it should be possible for the author to make that 
> island non-selectable so that you can select text from one side to the other 
> but not the island itself. (Typically this enables the inlining of 
> affordances.)
> 
> Reconsidering your objection, I wonder if it really is a problem? Overlapping 
> ranges: well, it would be weird, but basically it strikes me as a "doctor it 
> hurts when I do this" problem, unless I'm missing something. Ranges in 
> completely different locations that are not visually disjoint: well, if you 
> do that, maybe you have a reason? Just because you can do something stupid 
> with an API doesn't mean that it's a stupid API.

One of the biggest problems with the existing editing API is that it's hard to 
use because it's high level and a lot of things could go wrong unless you're 
very careful.  I don't think we want to introduce a yet another hard-to-use API 
if we can avoid it.

 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.
>>> 
>>> I don't disagree that it can be hard to handle, but I'm not sure
>>> that that's indicative of anything. Most scripts only handle one
>>> selection because AFAIK only Gecko ever supported more than one.
>> 
>> Given Gecko itself doesn't handle applying editing operations to
>> multiple ranges well from what I've heard, I'm not certain we can
>> expect web developers to get them right especially in the context
>> where disjoint multi-range selection is needed; e.g. bidirectional
>> text, exotic layout model.
> 
> I don't think that what is supported in any browser today in terms of 
> contentEditable should be seen as a limitation on what Web developers can 
> achieve. I'm very much certain that they can do better.

Again, I have a hard time believing that a novice Web developer who has never 
seen bidirectional text in his life could get this right.  It's the same issue 
as accessibility or IME issue we've been discussing in another thread.  It's 
extremely easy to get corner cases wrong.  Given the whole issue with the 
existing editing API is that it's buggy in edge cases, we need to be extremely 
careful not to introduce a yet another API that's error-prone.

> Thinking about this some more, I wonder if the problem is not less common 
> than I initially thought, though. If you consider the following text:
> 
>  ltr rtl ltr
> 
> You definitely need multiranges while the selection is in progress if

Re: Composition, IME, etc.

[Ryosuke Niwa]

On Jun 23, 2014, at 8:45 AM, Robin Berjon  wrote:

> On 06/06/2014 19:13 , Ryosuke Niwa wrote:
>> On Jun 6, 2014, at 7:24 AM, Robin Berjon  wrote:
>>> In order to handle them you have two basic options:
>>> 
>>> a) Let the browser handle them for you (possibly calling up some
>>> platform functionality). This works as closely to user expectations
>>> as a Web app can hope to get but how do you render it? If it
>>> touches your DOM then you lose the indirection you need for
>>> sensible editing; if it doesn't I don't know how you show it.
>>> 
>>> b) Provide the app with enough information to do the right thing.
>>> This gives you the indirection, but "doing the right thing" can be
>>> pretty hard.
>>> 
>>> I am still leaning towards (b) being the approach to follow, but
>>> I'll admit that that's mostly because I can't see how to make (a)
>>> actually work. If (b) is the way, then we need to make sure that
>>> it's not so hard that everyone gets it wrong as soon as the input
>>> is anything other than basic English.
>> 
>> I'm not convinced b is the right approach.
> 
> As I said though, it's better than (a) which is largely unusable.
> 
> That said, I have a proposal that improves on (b) and I believes addresses 
> your concerns (essentially by merging both approaches into a single one).
> 
>>> If the browser doesn't know because the platform can't tell the
>>> difference between Korean and Japanese (a problem with which
>>> Unicode doesn't help) then there really isn't much that we can do
>>> to help the Web app.
>> 
>> This predicates on using approach b.  I'm not convinced that that's
>> the right thing to do here.
> 
> No, it doesn't. If the browser has no clue whatsoever how to present 
> composition then it can't offer the right UI itself any more than it can help 
> the application do things well. I am merely ruling that situation, which you 
> mentioned, out as unsolvable (by us).
> 
>>> However if the browser knows, it can provide the app with
>>> information. I don't have enough expertise to know how much
>>> information it needs to convey — if it's mostly style that can be
>>> done (it might be unwieldy to handle but we can look at it).
>> 
>> The problem here is that we don't know if underlining is the only
>> difference input methods ever need.  We could imagine future new UI
>> paradigms would require other styling such as bolding text, enlarging
>> the text for easier readability while typing, etc...
> 
> I never said that the browser would only provide underlining information. I 
> said it can convey *style*. If it knows that the specific composition being 
> carried out requires bolding, then it could provide the matching CSS 
> declaration. If there is an alien composition method that requires red 
> blinking with a green top border, it could convey that.
> 
> Having said that, having the browser convey style information to the script 
> with the expectation that the script would create the correct Range for the 
> composition in progress and apply that style to it, even though possible, 
> seems like a lot of hoops to jump through that are essentially guaranteed to 
> be exactly the same in every single instance.
> 
> I think we can do better. It's a complicated-sounding solution but the 
> problem is itself complex, and I *think* that it is doable and the best of 
> all options I can think of.
> 
> To restate the problem:
> 
>  • We don't want the browser editing the DOM directly because that just 
> creates madness
>  • We want to enable any manner of text composition, from a broad array of 
> options, while showing the best UI for the user.
> 
> These two requirements are at odds because rich, powerful composition that is 
> great for the user *has* to rely on the browser, but the logical way for the 
> browser to expose that is to use the DOM.
> 
> The idea to ally both is to use a "shadow text insertion point". Basically, 
> it is a small DOM tree injected as a shadow at the insertion point (with 
> author styles applied to it). The browser can do *anything* it wants in there 
> in order to create a correct editing UI. While composition is ongoing, the 
> script still receives composition events but can safely just ignore them for 
> the vast majority of cases (since you can't generally usefully validate 
> composition in progress anyway). When the composition terminates, the input 
> event contains the *text* content of the shadow DOM, which is reclaimed.

That's an interesting idea. It does works around the issue of UA having to draw 
the composting text while still allowing authors to style it.

> I guess that the shadow text insertion point would participate in the tree in 
> the same way that a pseudo-element does. (Yes, I realise this basically means 
> "magic".)
> 
> I believe this works well for the insertion of new text; I need to mull it 
> over further to think about editing existing content (notably the case that 
> happens in autocorrect, predictive, and I believe Kot

Re: Editing with native UI

[Ryosuke Niwa]

On Jun 30, 2014, at 4:19 PM, Ryosuke Niwa  wrote:

> 
> On Jun 24, 2014, at 3:44 AM, Robin Berjon  wrote:
> 
>> On 24/06/2014 00:38 , Ben Peters wrote:
 Also, if the browser includes a "bold" command by default and I
 don't support bolding and therefore cancel the event, the user who
 has been relying on the native UI is getting the worst possible
 experience: native controls that do nothing at all.
>> >
>>> This doesn't seem like an insurmountable problem. We can provide a
>>> way for sites to indicate that they support certain commands and not
>>> others, similar to queryCommandEnabled(), which has a return value
>>> that could be modified by javascript (perhaps by an event, say
>>> QueryCommandEvent). Then the browser could choose not to show buttons
>>> for commands that are disabled.
>> 
>> Yes, this is possible, but I see problems with it.
>> 
>> First, it has to be white-list based. An option to just disable things would 
>> not be resilient in the face of browser vendors adding stuff.
>> 
>> Second, it doesn't address the point made below about native UI exposing a 
>> likely non-natural subset of the commands I wish to support.
> 
> That presumes an opt-out mechanism to enable native UI.  If we had used 
> opt-in instead, then we wouldn't have this issue.
> 
>> Third, I sense the sort of list that tends to acquire proprietary extensions 
>> over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads 
>> developers to have to keep adding new values if they want a half-sane native 
>> UI that matches their usage (for reference, see the current favicon mess).
> 
> On the contrary, white-listing a list of editing command that an editor 
> supports

allowss

> UA to disable menu items corresponding for those supported editing actions.  
> This is crural for not confusing end users.
> 
>> Finally, it feels an architecturally bad idea to require developers to 
>> specify the same information more than once. If my own toolbar has bold and 
>> italic, and I tell the browser that I want its native UI to expose bold and 
>> italic, then go ahead and add underlining to my toolbar I can easily forget 
>> to also tell the UA (granted, libraries can paper over that, but it becomes 
>> a tools-will-save-us situation).
>> 
>> Building on top of the infrastructure that HTML is providing to define menus 
>> and commands, we can get something that is:
>> 
>>  • White-list based;
>>  • Has the exact set of commands I wish to expose;
>>  • Does not lend itself to proprietary drift;
>>  • Is specified once.
>> 
>> Note that if what HTML 5.1 is currently doing in this area isn't good 
>> enough, we can (and should) definitely improve it. Right now it's not, to 
>> the best of my knowledge, implemented broadly enough that we can't change it.
> 
> There is a list of problems with the current editing API:
> Undo/redo menu doesn't get enabled/disabled in accordance with the app's 
> intrernal undo stack.
> 
> - R. Niwa
> 

Re: Editing with native UI

[Ryosuke Niwa]

On Jun 24, 2014, at 3:44 AM, Robin Berjon  wrote:

> On 24/06/2014 00:38 , Ben Peters wrote:
>>> Also, if the browser includes a "bold" command by default and I
>>> don't support bolding and therefore cancel the event, the user who
>>> has been relying on the native UI is getting the worst possible
>>> experience: native controls that do nothing at all.
> >
>> This doesn't seem like an insurmountable problem. We can provide a
>> way for sites to indicate that they support certain commands and not
>> others, similar to queryCommandEnabled(), which has a return value
>> that could be modified by javascript (perhaps by an event, say
>> QueryCommandEvent). Then the browser could choose not to show buttons
>> for commands that are disabled.
> 
> Yes, this is possible, but I see problems with it.
> 
> First, it has to be white-list based. An option to just disable things would 
> not be resilient in the face of browser vendors adding stuff.
> 
> Second, it doesn't address the point made below about native UI exposing a 
> likely non-natural subset of the commands I wish to support.

That presumes an opt-out mechanism to enable native UI.  If we had used opt-in 
instead, then we wouldn't have this issue.

> Third, I sense the sort of list that tends to acquire proprietary extensions 
> over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads 
> developers to have to keep adding new values if they want a half-sane native 
> UI that matches their usage (for reference, see the current favicon mess).

On the contrary, white-listing a list of editing command that an editor 
supports UA to disable menu items corresponding for those supported editing 
actions.  This is crural for not confusing end users.

> Finally, it feels an architecturally bad idea to require developers to 
> specify the same information more than once. If my own toolbar has bold and 
> italic, and I tell the browser that I want its native UI to expose bold and 
> italic, then go ahead and add underlining to my toolbar I can easily forget 
> to also tell the UA (granted, libraries can paper over that, but it becomes a 
> tools-will-save-us situation).
> 
> Building on top of the infrastructure that HTML is providing to define menus 
> and commands, we can get something that is:
> 
>  • White-list based;
>  • Has the exact set of commands I wish to expose;
>  • Does not lend itself to proprietary drift;
>  • Is specified once.
> 
> Note that if what HTML 5.1 is currently doing in this area isn't good enough, 
> we can (and should) definitely improve it. Right now it's not, to the best of 
> my knowledge, implemented broadly enough that we can't change it.

There is a list of problems with the current editing API:
Undo/redo menu doesn't get enabled/disabled in accordance with the app's 
intrernal undo stack.

- R. Niwa

Re: File API: Blob URL origin

[Glenn Maynard]

On Mon, Jun 30, 2014 at 3:57 PM, Anne van Kesteren  wrote:

> On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan 
> wrote:
> > They are! That is, at the time the method URL.createObjectURL(blob) is
> > called on blob, that method adds an entry to the Blob URL Store:
> > http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry
> >
> > I’ve only defined identifier extraction for use with adding an entry. Is
> > that wrong?
>
> It seems like you could define identifier creation, use that, use the
> return value to add an entry, and then return "blob:" + the return
> value. Creating a URL first and then parsing it again to extract
> something seems needlessly complicated.
>

Why would the identifier not just be the blob URL itself?  The spec
currently makes the identifier just the scheme data, which seems much more
complex than it needs to be.  revokeObjectURL should simply be "Remove the
entry from the Blob URL Store for URL."  If we want to allow revoking URLs
that have a fragment attached it'd still need to strip it off; Firefox does
this, but Chrome doesn't.

Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg.
"Blob:..." won't revoke the URL, or uppercasing the hostname portion in
Chrome.  Using the whole URL as the identifier makes this easy to do.

"Subsequent attempts to dereference url must return a network error" should
be removed.  That should already be the consequence of unregistering the
URL, so this is a redundant requirement.

-- 
Glenn Maynard

Re: File API: Blob URL origin

[Arun Ranganathan]

On Jun 30, 2014, at 4:57 PM, Anne van Kesteren  wrote:

> On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan  wrote:
>> They are! That is, at the time the method URL.createObjectURL(blob) is
>> called on blob, that method adds an entry to the Blob URL Store:
>> http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry
>> 
>> I’ve only defined identifier extraction for use with adding an entry. Is
>> that wrong?
> 
> It seems like you could define identifier creation, use that, use the
> return value to add an entry, and then return "blob:" + the return
> value. Creating a URL first and then parsing it again to extract
> something seems needlessly complicated.



Well, the best way to define URL.revokeObjectURL(blobURL) seemed to be in terms 
of parsing to extract identifier (scheme data) and then delete the entry 
corresponding to identifier.

But you’re absolutely right that URL.create* methods shouldn’t have a 
dependency on the basic URL parser, and so I’ve redefined those methods along 
the lines you say above (namely, defining identifier creation, and then Blob 
URL creation).

That’s http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking in today’s 
editor’s draft.

(So *now* maybe the path is clear for Fetch with Blobs.)

— A*

Re: [editing] selection across editing host boundaries

[Ryosuke Niwa]

On Jun 24, 2014, at 6:39 AM, Piotr Koszuliński  
wrote:

> 
> On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon  wrote:
> On 23/06/2014 20:33 , Johannes Wilm wrote:
> I filed bugs on this on both Firefox and Chrome in spring 2013. It was
> briefly fixed in Chrome, but the fix was then retracted and we never
> heard any more of it. It was also reported in Firefox by someone else in
> 2011. [1]
> 
> I also had some contact with Webkit people working in this area who
> unfortunately didn't find the behavior to be problematic.
> 
> This is probably the main reason why at least I am wondering if editing
> maybe just is an area that won't be of enough interest to browser makers
> to ever fix and that it may therefore just make more sense to just ask
> them to remove it and do everything in Javascript. But now it seeems
> this is about to change, which would be really really good.
> 
> >From discussions I've had in the past on this topic, it's not so much that 
> >browser-folks don't want to fix this. The problem is more that 1) this is 
> >hard, so fixing can often only happen if someone really owns the problem 
> >rather than contributing the odd fix, and such a person isn't always 
> >available; 2) the current state of contentEditable is such a mess, notably 
> >with libraries doing per-UA workarounds, that fixes that make the behaviour 
> >globally saner actually break deployed code.
> 
> This has conspired to make the situation rot. Hopefully we can fix this with 
> the new tack taken here, notably by using contentEditable=cursor as a "sanity 
> hook" which doesn't have to be backwards compatible with the existing madness.
> 
> I am happy to see more cases that force us to propose something new, instead 
> of patching rotting contentEditable=true :D.
>  
> 
> That's all nice and well, but what should the range be in the following cases:
> 
>   A:
>   blah foo| blah
> 
>   B:
>   blah [foo] blah
> 
>   C:
>   bl[ah foo bl]ah
> 
>   D:
>   blah f[oo bl]ah
> 
>   E:
>   blah |foo blah
> 
> Or in this:
> 
>   F:
>   
> blah
> |blah
>   
> 
>   F2:
>   
> blah
> |
>   
> 
> or just for kicks, one could make the argument that this is different:
> 
>   G:
>   
> blah
> |blah
>   
> 
> ?
> 
> I think that we can start to solve this in the following manner:
> 
>   • When a deletion event would produce a range crossing an odd number of 
> editing boundaries (either because there's a selection doing so in the sum of 
> its ranges or for instance given backspace in case A above) then its range is 
> empty and corresponds to a collapsed range a the cursor position (this is 
> defined even for selections).
> 
>   • Conversely, when it would cross an even number of editing boundaries, 
> then the range covers them.
> 
>   • Deletion events capture information expressing the direction of the 
> deletion ("previous", "next", or possibly "both" in the delete-line case). 
> This makes it possible for script to know how to hand the empty-range case.
> 
>   • Additionally, the deletion event can expose convenient information about 
> the editing boundaries being crossed, their number, their hosts.

Could you list use cases that support the above behaviors?  I agree all these 
recent discussions about editing is great but I've got a feeling that we've 
been spending too much time talking about solutions without really 
understanding use cases and the full scope of the problem we're trying to solve.


> This means that, assuming backspace, the cases above can be handled as 
> follows:
> 
> A: empty range, the script can decide whether to select or delete the 
> non-editable content (direction "previous").
> B: a range containing non-editable. Presumably deleted.
> C: same as B with some extra content on both sides. Presumably deleted.
> D: empty range, the script can decide what makes most sense. (Stabbing the 
> user in the face sounds good.)
> E: empty range, the script decides which is best.
> 
> For F, F2, G, and an awful lot of other cases (dt/dd, td, etc.) I think we 
> should take the minimalist approach: just produce a deletion event indicating 
> its direction but with an empty range. Scripts can decide if they wish to 
> merge elements, delete empty ones, outdent, etc.
> 
> 
> This is getting complicated enough (and I haven't mentioned other cases such 
> as br, script, hr, td, img, video...) that I wonder if the Deletion event 
> shouldn't have its own spec.
> 
> I agree about A, B and C. Selection in D in my opinion should not be possible 
> (I'll comment on that later [1]). Selection in E also should not be possible 
> because empty selection can't be made in non-editable element.

It does seem that disallowing selections that cross odd numbers of editing 
boundaries would simplify the issue.  Perhaps UA could auto-correct such 
selections before presenting it to the user so that the user would not get 
confused by editing actions not being applied to the entirely of such selection.

I do see one

Re: Should / Can an EventHandler throw a stack overflow exception?

[Anne van Kesteren]

On Mon, Jun 30, 2014 at 6:01 PM, Boris Zbarsky  wrote:
> On 6/30/14, 4:40 AM, Anne van Kesteren wrote:
>> Are stack overflow exceptions even a thing per standards?
>
> No.
>
> However, they come up pretty regularly in practice.  In fact, some sites
> depend on them for proper functioning.  :(

Paging Allen. If defining this needs to start anywhere, it would
probably be ECMAScript.


-- 
http://annevankesteren.nl/

Re: File API: Blob URL origin

[Anne van Kesteren]

On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan  wrote:
> They are! That is, at the time the method URL.createObjectURL(blob) is
> called on blob, that method adds an entry to the Blob URL Store:
> http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry
>
> I’ve only defined identifier extraction for use with adding an entry. Is
> that wrong?

It seems like you could define identifier creation, use that, use the
return value to add an entry, and then return "blob:" + the return
value. Creating a URL first and then parsing it again to extract
something seems needlessly complicated.


-- 
http://annevankesteren.nl/

Re: File API: Blob URL origin

[Arun Ranganathan]

On Jun 30, 2014, at 4:20 PM, Anne van Kesteren  wrote:

> I don't really understand this. Entries should be added when a blob
> URL is created.


They are! That is, at the time the method URL.createObjectURL(blob) is called 
on blob, that method adds an entry to the Blob URL Store: 
http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry

I’ve only defined identifier extraction for use with adding an entry. Is that 
wrong?


> And should be checked/removed when a blob URL is used
> (through parsing it in the URL parser, as defined by the URL parser).


Yes, this is when URL parser *checks* the Blob URL Store, *after* entries have 
either been added or are not present (which generates a network error).


> There should be no need for such a definition in the File API specification.


Since adding scheme data as an identifer to the Blob URL Store is the 
requirement, we only use the basic URL parser to get the scheme data from a 
generated URL to add to the Blob URL Store.

— A*

Re: [editing] Leading with ContentEditable=Minimal

[Johannes Wilm]

On Mon, Jun 30, 2014 at 10:01 PM, Ryosuke Niwa  wrote:


>
> On Jun 26, 2014, at 3:24 PM, Olivier F  wrote:
>


> I agree these all seem the same. Here are a few other use cases I can
> think of:
>
> * Create a web-based structured content editor, where the allowable DOM
> elements and/or classes in the content are pre-defined.
>
>
> Could you elaborate on the use case of making such an editor?  e.g.
> allowing only certain types of styling in comments.
>

We do that in Fidus Writer.  Part of the point is to keep the structure of
the document semantically defined. Users can't change font sizes of
individual words, etc. . This is because one of the main tasks of
scientific journal editors who currently receive drafts in Word or
Libreoffice format have to undo all the manual styling the writers have
added in order to get everything to look in a similar way. we simply take
those styling possibilities away so that we can define the entire design
through one stylesheet as well as easily convert to other formats, such as
LaTex or an Epub, and be sure that we cover all formatting tags that were
used.

>
> * A complete book/whatever editor, which can contain areas of non-editable
> content, nested editable content, etc... See fiduswriter.org, and what
> CKEditor are doing with widgets.
>
>
> Could you elaborate on how non-editable content appears/used inside an
> editable content?
>

We also do that - for example in the case of formulas. Generally the text
is editable near-Wysiwyg style. But when it comes to formulas, we let the
user enter them in Latex format and display the result using mathjax. Each
formula object within the text is a noneditable island. If the user clicks
on it with the mouse, he can change the formula.

Another example are figures: We want them to always be block elements and
to have exactly one caption without styling. They are therefore
non-editable isalnds and if the user clicks on them he can change the
figure's display and the caption text.


>
> * Browser-based code editor. Currently CodeMirror and others go through
> amazing lengths to provide something that looks and behaves like a desktop
> code editor.
> * Browser based "word art" generator where end-user types some text and it
> renders in 3D along a curve and in rainbow colors on a .
>
>
> These are great use cases.
>
> I'd throw in two more:
>
>- Web-based DTP application: The app can creates a document that
>contains pagination, columns, and a complex illustrations.  It needs to let
>users edit any text that appears in the document.  Each editable text needs
>to be accessible, and styles applied to text need to be backed by the
>application's internal model of the document.
>
> Yes, but wouldn't this require some fragmentation logic? To create
something like what Quark Xpress was in the 1990s, I think you'd need CSS
Regions or equivalent. It seems as if that would be a little outside of the
scope of the caret moving logic, or how do you mean? I would find it great
if this ever happens, but as I understand it the whole fragmentation debate
was left aside for a while.


>
>- Semantic HTML WYSIWYG editor for a blogging platform: The editor
>needs to able to add both semantic and visual annotation to the document as
>it will be published as a blog.  Headings are to be marked up with h1. h2,
>etc... and each acronyms, abbreviations, and so forth are marked up with
>respective HTML elements.  However, the editor also supports visual
>annotations such as bolding, italicizing, and enlarging text, each of which
>will be interpreted by the editor to respective underlying semantics in
>HTML.
>
>
Yes, and in order to keep things consistent he may want to disallow certain
types of styling. A few years ago it was common to see people with Joomla
sites who just pasted the text into the editor after copying it from a word
processor. Each blog post therefore ended up having very different styling.

>
>
> I picked these examples because they illustrate why separate building
> blocks are the right way to go. I would expect the developer of the
> structured content editor to leverage cursor=true, commandEvents and
> Selections API, and if it's available some sort of text insert mechanism.
> In contrast the "word art" developer would only leverage commandEvents and
> will have to draw their own cursor and selections along with their fancy
> curved 3D text.
>
>
> Thanks for a great list of use cases.  Now we need a required set of
> features/API for each use case.  We can then evaluate whether what has been
> discussed thus far satisfy enough use cases or not.
>
> - R. Niwa
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.o rg

Re: File API: Blob URL origin

[Anne van Kesteren]

On Mon, Jun 30, 2014 at 8:45 PM, Arun Ranganathan  wrote:
> Removed origin extraction from FIle API, but added identifier extraction 
> (based on the same model — that is, running the basic URL parser). This makes 
> adding entires to the Blob URL Store clearer.

I don't really understand this. Entries should be added when a blob
URL is created. And should be checked/removed when a blob URL is used
(through parsing it in the URL parser, as defined by the URL parser).

There should be no need for such a definition in the File API specification.


-- 
http://annevankesteren.nl/

Re: [editing] Leading with ContentEditable=Minimal

[Ryosuke Niwa]

On Jun 29, 2014, at 10:22 PM, Johannes Wilm  wrote:

> Another use case: Create a track changes function within an editor (like 
> https://github.com/NYTimes/ice ) that really should be run MVC in order to 
> keep the code somewhat readable. Currently ICE breaks whenever any of the 
> browser makers decide to change anything about contenteditable. 

This is a great concrete use case.

On Jun 26, 2014, at 3:24 PM, Olivier F  wrote:

> On Thu, Jun 26, 2014 at 3:51 AM, Robin Berjon  wrote:
> On 24/06/2014 20:09 , Ben Peters wrote:
> Problems:
> * ContentEditable is too complex and buggy to be usable as-is
> * ContentEditable does not easily enable the wide range of editing scenarios
> 
> Complex and buggy aren't necessarily show-stoppers. With hard work it should 
> be possible to take the current Editing APIs draft and progressively iron out 
> most of the kinks. It's difficult, but difficult things have been done before.
> 
> The main problem here is that even if we did that we still wouldn't have a 
> usable system. And I would say that the issue isn't so much that it doesn't 
> enable scenarios more than that it works actively hard to make them hard to 
> implement :)
> 
> Maybe this can be captured as "Does not support 
> http://extensiblewebmanifesto.org/";.
> 
> I agree with this. The problem is not complexity. I don't expect implementing 
> a well-appointed custom content editor will be anything but complex. 
> 
> The problem is that contenteditable=true is a high-level API which by 
> definition has to assume a lot and do a lot. This prevents custom behavior 
> from being implemented without clashing with the "helpful" high level 
> behavior that the UA is expected to do.
> 
> Our goal should be to provide a set of low-level building blocks for 
> text/content editing. I think that with cursor=true, and commandEvents, and 
> improved Selection API we're headed in the right direction.

I don't think we can set a goal without first enumerating use cases and the 
problem we're trying to solve. 

> Use Cases:
> * Create a js framework that enables a WYSIWYG editor and works the same in 
> all browsers with little browser-specific code

This one is a bit vague as a use case.  Are you thinking of a WYSIWYG editor 
you see on CMS or a blog editor?  Or does it include something like EitherPad?  
I think we need to be much more concrete.

> * Use a js framework to insert a customized editor into an email client
> * Use a js framework to insert a customized editor into a blog
> * Use a js framework to insert a customized editor into a wiki
> 
> Aren't those the same as the previous one?
> 
> I agree these all seem the same. Here are a few other use cases I can think 
> of:
> 
> * Create a web-based structured content editor, where the allowable DOM 
> elements and/or classes in the content are pre-defined.

Could you elaborate on the use case of making such an editor?  e.g. allowing 
only certain types of styling in comments.

> * A complete book/whatever editor, which can contain areas of non-editable 
> content, nested editable content, etc... See fiduswriter.org, and what 
> CKEditor are doing with widgets.

Could you elaborate on how non-editable content appears/used inside an editable 
content?

> * Browser-based code editor. Currently CodeMirror and others go through 
> amazing lengths to provide something that looks and behaves like a desktop 
> code editor.
> * Browser based "word art" generator where end-user types some text and it 
> renders in 3D along a curve and in rainbow colors on a .

These are great use cases.

I'd throw in two more:
Web-based DTP application: The app can creates a document that contains 
pagination, columns, and a complex illustrations.  It needs to let users edit 
any text that appears in the document.  Each editable text needs to be 
accessible, and styles applied to text need to be backed by the application's 
internal model of the document.
Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able 
to add both semantic and visual annotation to the document as it will be 
published as a blog.  Headings are to be marked up with h1. h2, etc... and each 
acronyms, abbreviations, and so forth are marked up with respective HTML 
elements.  However, the editor also supports visual annotations such as 
bolding, italicizing, and enlarging text, each of which will be interpreted by 
the editor to respective underlying semantics in HTML.


> I picked these examples because they illustrate why separate building blocks 
> are the right way to go. I would expect the developer of the structured 
> content editor to leverage cursor=true, commandEvents and Selections API, and 
> if it's available some sort of text insert mechanism. In contrast the "word 
> art" developer would only leverage commandEvents and will have to draw their 
> own cursor and selections along with their fancy curved 3D text.


Thanks for a great list of use cases.  Now we need a required set of

Re: File API: Blob URL origin

[Arun Ranganathan]

On Jun 28, 2014, at 4:42 AM, Anne van Kesteren  wrote:

> I now defined the origin for blob URLs:
> http://url.spec.whatwg.org/#concept-url-origin Sorry for the delay.
> 
> Still need to work out the correct Fetch integration.
> 


Thanks :)

Removed origin extraction from FIle API, but added identifier extraction (based 
on the same model — that is, running the basic URL parser). This makes adding 
entires to the Blob URL Store clearer.

I think the Blob pieces for Fetch are in place now.

http://dev.w3.org/2006/webapi/FileAPI

— A* 

Re: Should / Can an EventHandler throw a stack overflow exception?

[Boris Zbarsky]

On 6/30/14, 4:40 AM, Anne van Kesteren wrote:

Are stack overflow exceptions even a thing per standards?


No.

However, they come up pretty regularly in practice.  In fact, some sites 
depend on them for proper functioning.  :(


-Boris

[Bug 26153] Allow ArrayBuffer as argument to send()

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26153

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Anne  ---
This is now allowed due to refactoring in terms of Fetch. The neutering issue
is not fixed however.

https://github.com/whatwg/xhr/commit/82e602e4507c19802c373bf19f5e956973f1c6c3

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26238] New: Add follow redirects back into WHATWG XHR specification

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26238

Bug ID: 26238
   Summary: Add follow redirects back into WHATWG XHR
specification
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: minor
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: jonat...@jooped.co.uk
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Add follow redirects back into WHATWG XHR specification:
http://xhr.spec.whatwg.org/

As mentioned on this post:
http://discourse.specifiction.org/t/followredirects-in-xmlhttprequest/420/11?u=jonathank

The intent is to put back in the followRedirects feature which was a security
improvement from the client side to prevent calls following to unexpected URL
changes.

The expected result when the AJAX request returns a redirect code and
followRedirects is disabled then it should return a network error.

This should follow the same definition as the original specification:
http://www.w3.org/TR/2010/WD-XMLHttpRequest2-20100907/#the-followredirects-attribute

However it shouldn't return a response if there is a redirect just a network
error to the callbacks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

usecases Re: [editing] Leading with ContentEditable=Minimal

[Charles McCathie Nevile]

On Mon, 30 Jun 2014 10:54:36 +0300, Robin Berjon  wrote:


On 30/06/2014 07:22 , Johannes Wilm wrote:

Another use case: Create a track changes function within an editor (like
https://github.com/NYTimes/ice ) that really should be run MVC in order
to keep the code somewhat readable. Currently ICE breaks whenever any of
the browser makers decide to change anything about contenteditable.


Oh yeah, anything involving tracking, OT, or whatever temporal really,  
really can't use the markup as its model. I'm surprised ICE went that  
way, it must be terribly painful.


Create an extension that substitutes an editor adapted to the user's needs  
for a default editing setup in an application.


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com

Re: Should / Can an EventHandler throw a stack overflow exception?

[Anne van Kesteren]

On Mon, Jun 30, 2014 at 10:27 AM, Yutaka Hirano  wrote:
> But it is unclear to me whether a stack overflow exception is counted
> as an exception thrown inside an event listener.

Are stack overflow exceptions even a thing per standards?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17713 is the issue on
clarifying exception behavior around events. (Please don't use DOM
Level 3 Events as a reference for implementing the event model.)


-- 
http://annevankesteren.nl/

Re: [editing] Leading with ContentEditable=Minimal

[Robin Berjon]

On 30/06/2014 07:22 , Johannes Wilm wrote:

Another use case: Create a track changes function within an editor (like
https://github.com/NYTimes/ice ) that really should be run MVC in order
to keep the code somewhat readable. Currently ICE breaks whenever any of
the browser makers decide to change anything about contenteditable.


Oh yeah, anything involving tracking, OT, or whatever temporal really, 
really can't use the markup as its model. I'm surprised ICE went that 
way, it must be terribly painful.


--
Robin Berjon - http://berjon.com/ - @robinberjon