Re: Pressing Enter in contenteditable: p or br or div?
On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote: BCC: whatwg, CC:public-webapps since discussion of the editing spec has moved I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Why? Also, I'd really like the default single-line container name to be configurable in some way. I agree. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. What is the use case for br that div doesn't cover? As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. Which apps use br? Could they switch to div without losing some functionality? I'm tempted to say that any block type should be allowed, I strongly disagree. Supporting any block type opens up for lots of bugs and weird cases. We should only support the types necessary to cover presented use cases. but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. Just use ul contenteditableli|/li/ul. li as defaultblock would result in invalid markup if there's no list (and when breaking out of a list, etc). Ojan On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). What behavior do we want? I ended up going with the general approach of IE/Opera: http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements It turns out WebKit and Opera make the insertParagraph command behave essentially like hitting Enter, so I actually wrote all the requirements there (IE's and Firefox's behavior for insertParagraph was very different and didn't seem useful): http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command The basic idea is that if the cursor isn't wrapped in a single-line container (address, dd, div, dt, h*, li, p, pre) then the current line gets wrapped in a p. Then the current single-line container is split in two, mostly. Exceptions are roughly: * For pre and address, insert a br instead of splitting the element. (This matches Firefox for pre and address, and Opera for pre but not address. IE/Chrome make multiple pres/addresses.) * For an empty li/dt/dd, destroy it and break out of its container, so hitting Enter twice in a list breaks out of the list. (Everyone does this for li, only Firefox does for dt/dd.) * If the cursor is at the end of an h* element, make the new element a p instead of a header. (Everyone does this.) * If the cursor is at the end of a dd/dt element, it switches to dt/dd respectively. (Only Firefox does this, but it makes sense.) Like the rest of the spec, this is still a rough draft and I haven't tried to pin corner cases down yet, so it's probably not advisable to try implementing it yet as written. As always, you can see how the spec implementation behaves for various input by looking at autoimplementation.html: http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph -- Simon Pieters Opera Software
querySelectorAll() -- selecting _immediate_ children of element
querySelector() and querySelectorAll() methods are exciting features, but they
do not allow select _immediate_ children of reference element.
To address this lack, we could use following syntax:
var divs = refElement.querySelectorAll(' DIV');
Here 'divs' variable contains list of DIV elements that are immediate children
(not just descendant elements) of reference element (refElement).
This syntax is extremely intuitive and BTW is supported in jQuery.
Other combinators (e.g. adjacent-sibling combinator) would have sense too, for
example:
var span = h1.querySelector('+ H2 SPAN');
'span' variable here contains DOM reference to SPAN elements inside H2 element
which is next sibling of H1 element:
h1.../h1
h2... span.../span .../h2
But fundamental missing demanded feature is ability to select _child_ elements
of reference element ( querySelectorAll(' DIV') ).
Since usecases are purely script-level, CSSWG has nothing to do with this
syntax. From selectors perspective, there is nothing new here: we have
reference element (in CSS, a selector is used in place of concrete element),
standard selector (DIV), and standard combinator between them.
An acceptable alternative to implied reference element would be using ':this'
pseudoclass:
var divs = refElement.querySelectorAll(':this DIV');
var span = h1.querySelector(':this + H2 SPAN');
Furthermore, :this pseudoclass would give us additional possibilities such as
selecting descendant elements via selectors _all_ parts of which matches to
descendants of reference element.
For example, following code will select all links that are descendants of _any_
paragraph (not necessarily descendants of reference element):
refElement.querySelectorAll('P A');
As opposed, this code:
refElement.querySelectorAll(':this P A');
would select links that are inside of paragraphs which _themselves_ are
descendants of the reference element.
Probably most DRY, usable, and flexible solution would be to allow both
syntaxes: implied reference element to use with combinators (where :this would
be just redundant), and explicit :this to use in conjunction with descendant
selectors (where it really gives additional useful possibilities missing in
current querySelector spec and implementations).
Thanks.
P.S. The proposal has been originally posted in public-script-coord
(http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0078.html )
but it seems public-webapps is probably more appropriate place for this.
[Bug 15470] New: Changing the selection creates a Range object
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470 Summary: Changing the selection creates a Range object Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: ann...@opera.com QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Make it explicit that once the user changes the selection a Range object is created and associated with the selection. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
Hi All, As I indicated in [1], WebApps already has a relatively large number of specs in progress and the group has agreed to add some new specs. As such, to review any new charter addition proposals, I think we need at least the following: 1. Relatively clear scope of the feature(s). (This information should be detailed enough for WG members with relevant IP to be able to make an IP assessment.) 2. Editor commitment(s) 3. Implementation commitments from at least two WG members 4. Testing commitment(s) Re the APIs in this thread - I think Glen's API proposal [2] adequately addresses #1 above and his previous responses imply support for #2 but it would be good for Glen, et al. to confirm. Re #3, other than Google, I don't believe any other implementor has voiced their support for WebApps adding these APIs. As such, I think we we need additional input on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.). Re the markup question - WebAppsdoes have some precedence for defining markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on whether or not WebApps should include the type of markup in the XG Report. I think the next step here is for WG members to submit comments on this question. In particular, proponents of including markup in WebApps' charter should respond to #1-4 above. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html On 1/5/12 6:49 AM, ext Satish S wrote: 2) How does the draft incorporate with the existing input speech API[1]? It seems to me as if it'd be best to define both the attribute as the DOM APIs in a single specification, also because they share several events (yet don't seem to be interchangeable) and the attribute already has an implementation. The input speech API proposal was implemented as input x-webkit-speech in Chromium a while ago. A lot of the developer feedback we received was about finer grained control including a javascript API and letting the web application decide how to present the user interface rather than tying it to the input element. The HTML Speech Incubator Group's final report [1] includes a reco element which addresses both these concerns and provides automatic binding of speech recognition results to existing HTML elements. We are not sure if the WebApps WG is a good place to work on standardising such markup elements, hence did not include in the simplified Javascript API [2]. If there is sufficient interest and scope in the WebApps WG charter for the Javascript API and markup, we are happy to combine them both in the proposal. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Thanks, Peter [1] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html On Thu, Jan 5, 2012 at 07:15, Glen Shires gshi...@google.com mailto:gshi...@google.com wrote: As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Because that work was so broad, Art Barstow asked (below) for a relatively specific proposal. We at Google are proposing that a subset of it be accepted as a work item by the Web Applications WG. Specifically, we are proposing this Javascript API [3], which enables web developers to incorporate speech recognition and synthesis into their web pages. This simplified subset enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control, and it supports the majority of use-cases in the Incubator Group's Final Report. We welcome your feedback and ask that the Web Applications WG consider accepting this Javascript API [3] as a work item. [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] report: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [3] API: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Bjorn Bringert Satish Sampath Glen Shires On Thu, Dec 22, 2011 at 11:38 AM, Glen Shires gshi...@google.com mailto:gshi...@google.com wrote: Milan, The IDLs contained
Re: [CORS] Does Origin have to be included in the Access-Control-Request-Headers field?
On Sat, 2011-12-17 at 16:10 +0100, Anne van Kesteren wrote: On Fri, 29 Jul 2011 14:25:07 +0200, Vladimir Dzhuvinov vladi...@dzhuvinov.com wrote: Regarding 6. Resource processing model: [item 3] A list of headers consisting of zero or more header field names that are supported by the resource.: Is this list supposed to be 1) of the non-simple headers only - as per http://dev.w3.org/2006/waf/access-control/#simple-header or 2) of all supported headers that the author may choose to set, including those that qualify as simple? Because right now the Java CORS filter expects to receive only non-simple headers in Access-Control-Request-Headers, and if for some reason the browser has decided to include a simple header, e.g. Accept, in the preflight request it won't be allowed to proceed. My apologies for forgetting to reply to this message. Fortunately it was still somewhere in my inbox! It seems your Java CORS filter has a bug as simple headers can be included there (for consistency). This and a few other issues with the CORS Filter were sorted out last year thanks to user feedback and patches. Happy new year, Anne! -- Vladimir Dzhuvinov :: vladi...@dzhuvinov.com
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
On 01/09/2012 04:59 PM, Arthur Barstow wrote: Hi All, As I indicated in [1], WebApps already has a relatively large number of specs in progress and the group has agreed to add some new specs. As such, to review any new charter addition proposals, I think we need at least the following: 1. Relatively clear scope of the feature(s). (This information should be detailed enough for WG members with relevant IP to be able to make an IP assessment.) 2. Editor commitment(s) 3. Implementation commitments from at least two WG members Is this really requirement nowadays? Is there for example commitment to implement File System API? http://dev.w3.org/2009/dap/file-system/file-dir-sys.html But anyway, I'm interested to implement the speech API, and as far as I know, also other people involved with Mozilla have shown interest. 4. Testing commitment(s) Re the APIs in this thread - I think Glen's API proposal [2] adequately addresses #1 above and his previous responses imply support for #2 but it would be good for Glen, et al. to confirm. Re #3, other than Google, I don't believe any other implementor has voiced their support for WebApps adding these APIs. As such, I think we we need additional input on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.). It doesn't matter too much to me in which group the API will be developed (except that I'm against doing it in HTML WG). WebApps is reasonably good place (if there won't be any IP issues.) -Olli Re the markup question - WebAppsdoes have some precedence for defining markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on whether or not WebApps should include the type of markup in the XG Report. I think the next step here is for WG members to submit comments on this question. In particular, proponents of including markup in WebApps' charter should respond to #1-4 above. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html On 1/5/12 6:49 AM, ext Satish S wrote: 2) How does the draft incorporate with the existing input speech API[1]? It seems to me as if it'd be best to define both the attribute as the DOM APIs in a single specification, also because they share several events (yet don't seem to be interchangeable) and the attribute already has an implementation. The input speech API proposal was implemented as input x-webkit-speech in Chromium a while ago. A lot of the developer feedback we received was about finer grained control including a javascript API and letting the web application decide how to present the user interface rather than tying it to the input element. The HTML Speech Incubator Group's final report [1] includes a reco element which addresses both these concerns and provides automatic binding of speech recognition results to existing HTML elements. We are not sure if the WebApps WG is a good place to work on standardising such markup elements, hence did not include in the simplified Javascript API [2]. If there is sufficient interest and scope in the WebApps WG charter for the Javascript API and markup, we are happy to combine them both in the proposal. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Thanks, Peter [1] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html On Thu, Jan 5, 2012 at 07:15, Glen Shires gshi...@google.com mailto:gshi...@google.com wrote: As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Because that work was so broad, Art Barstow asked (below) for a relatively specific proposal. We at Google are proposing that a subset of it be accepted as a work item by the Web Applications WG. Specifically, we are proposing this Javascript API [3], which enables web developers to incorporate speech recognition and synthesis into their web pages. This simplified subset enables developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control, and it supports the majority of use-cases in the Incubator Group's Final Report. We welcome your feedback and ask that the Web Applications WG consider accepting this Javascript API [3] as a work item. [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] report:
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
On 01/09/2012 06:17 PM, Young, Milan wrote: To clarify, are you interested in developing the entirety of the JS API we developed in the HTML Speech XG, or just the subset proposed by Google? Not sure if you sent the reply to me only on purpose. CCing the WG and XG lists. Since from practical point of view the API+protocol XG defined is a huge thing to implement at once, it makes sense to implement it in pieces. Something like (1) Initial API implementation. Some subset of what XG defined Not necessarily exactly what Google proposed but something close to it. Support for remote speech services could be in the initial API, but if UA doesn't implement the protocol, it would just fail when trying to connect to remove services. (2) Simultaneously or later - depending on the protocol standardization in IETF or elsewhere - support remote speech services (3) implement some more of the API XG defined (if needed by web developers or web services) (4) Implement reco? I'm not at all convinced we need reco element since automatic value binding makes it just a bit strange and inconsistent. This is the way web APIs tend to evolve. Implement first something quite small, and then add new features if/when needed. -Olli Thanks -Original Message- From: Olli Pettay [mailto:olli.pet...@helsinki.fi] Sent: Monday, January 09, 2012 8:13 AM To: Arthur Barstow Cc: ext Satish S; Peter Beverloo; Glen Shires; public-webapps@w3.org; public-xg-htmlspe...@w3.org; Dan Burnett Subject: Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization On 01/09/2012 04:59 PM, Arthur Barstow wrote: Hi All, As I indicated in [1], WebApps already has a relatively large number of specs in progress and the group has agreed to add some new specs. As such, to review any new charter addition proposals, I think we need at least the following: 1. Relatively clear scope of the feature(s). (This information should be detailed enough for WG members with relevant IP to be able to make an IP assessment.) 2. Editor commitment(s) 3. Implementation commitments from at least two WG members Is this really requirement nowadays? Is there for example commitment to implement File System API? http://dev.w3.org/2009/dap/file-system/file-dir-sys.html But anyway, I'm interested to implement the speech API, and as far as I know, also other people involved with Mozilla have shown interest. 4. Testing commitment(s) Re the APIs in this thread - I think Glen's API proposal [2] adequately addresses #1 above and his previous responses imply support for #2 but it would be good for Glen, et al. to confirm. Re #3, other than Google, I don't believe any other implementor has voiced their support for WebApps adding these APIs. As such, I think we we need additional input on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.). It doesn't matter too much to me in which group the API will be developed (except that I'm against doing it in HTML WG). WebApps is reasonably good place (if there won't be any IP issues.) -Olli Re the markup question - WebAppsdoes have some precedence for defining markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on whether or not WebApps should include the type of markup in the XG Report. I think the next step here is for WG members to submit comments on this question. In particular, proponents of including markup in WebApps' charter should respond to #1-4 above. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/s peechapi.html On 1/5/12 6:49 AM, ext Satish S wrote: 2) How does the draft incorporate with the existinginput speech API[1]? It seems to me as if it'd be best to define both the attribute as the DOM APIs in a single specification, also because they share several events (yet don't seem to be interchangeable) and the attribute already has an implementation. Theinput speech API proposal was implemented asinput x-webkit-speech in Chromium a while ago. A lot of the developer feedback we received was about finer grained control including a javascript API and letting the web application decide how to present the user interface rather than tying it to theinput element. The HTML Speech Incubator Group's final report [1] includes areco element which addresses both these concerns and provides automatic binding of speech recognition results to existing HTML elements. We are not sure if the WebApps WG is a good place to work on standardising such markup elements, hence did not include in the simplified Javascript API [2]. If there is sufficient interest and scope in the WebApps WG charter for the Javascript API and markup, we are happy to combine them both in the proposal. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2]
Requirements for new work [Was: Re: Speech Recognition and Text-to-Speech Javascript API]
On 1/9/12 11:12 AM, ext Olli Pettay wrote: On 01/09/2012 04:59 PM, Arthur Barstow wrote: As I indicated in [1], WebApps already has a relatively large number of specs in progress and the group has agreed to add some new specs. As such, to review any new charter addition proposals, I think we need at least the following: 3. Implementation commitments from at least two WG members Is this really requirement nowadays? Strictly speaking No. However, I think it is a useful data point when evaluating a proposal, especially since a spec cannot advance to Recommendation without two or more implementations. OTOH, I also think we need to be flexible enough to accommodate a new feature proposal where there is lots of interest in fleshing out the details yet the details are still too vague for someone to make an implementation commitment. But anyway, I'm interested to implement the speech API, and as far as I know, also other people involved with Mozilla have shown interest. Thanks for this feedback. -AB
