[Bug 26065] New: [Explainer]:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26065 Bug ID: 26065 Summary: [Explainer]: Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: bartonphill...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14949 Code snip: "this._root.querySelector('hh').textContent = fmt(now.getHours()); this._root.querySelector('sep').style.visibility = now.getSeconds() % 2 ? 'visible' : 'hidden'; this._root.querySelector('mm').textContent = fmt(now.getMinutes());" End snip: Here we should have '#hh', '#sep' and '$mm'. Doesn't anyone try to run the code to see if it has a chance of being correct? -- You are receiving this mail because: You are on the CC list for the bug.
[editing] Best Time for Recurring Call
Hello Web Apps, Our recent call [1] regarding HTML Editing (contentEditable, CommandEvent) was quite valuable. It seems valuable to have a time reserved for future calls, though it will likely not be used every week. If you are interested in participating, please fill out the Doodle poll below to indicate what times work best for you. The poll contains Pacific Daylight Times 8-10am and 5-6pm (converter available [2]), Monday-Friday. Ignore the specific dates because the call will be used as-needed for any given week, with at least 48 hours advance notice (typically 7 days). This poll will close June 18th. http://doodle.com/d8m624mfcvutnf4w Ben Peters [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0842.html [2] http://www.worldtimebuddy.com/?pl=1&lid=5391959,5128581,2950159,1850147&h=2950159
Check out my profile on LinkedIn
LinkedIn public-webapps, I'd like to add you to my professional network on LinkedIn. - Henry Henry Story W3C WebID XG chair at The Apache Software Foundation Paris Area, France Confirm that you know Henry Story: https://www.linkedin.com/e/2mutdc-hwahk8hj-4d/isd/5882435765459238912/QGriTuf8/?hs=false&tok=0o-tvurmBHGSg1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/2mutdc-hwahk8hj-4d/uqqYSuw9K9zoOARrRuv3fTvX8qkgHswM12/goo/public-webapps%40w3%2Eorg/20061/I7245534365_1/?hs=false&tok=1YhNrn4gNHGSg1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
re: contentEditable=minimal
Hello Everyone, The idea of a contentEditable spec that is usable for developers gives me so much hope that I am drawn to make my very first comment on a W3 list. First, thank-you Ben Peters for the original post. I am an independent web developer who is frustrated because I feel there is a whole class of web-apps that are not seeing the light of day because current cE makes it too difficult. So, we really need this. By "this", I mean the building blocks for a fully custom but highly functional and usable content editor in the browser. I have read every message on this topic in this list since May so I can see along with everybody else that this is a very complex problem. It sounds like we should be able to break the problem down into parts, so this is how I see things: 1. Create a cE=minimal/whatever spec that specifies that it does very little by default. Its behavior should be well-defined and highly predictable. It would actually do too little on its own to be called a "rich editor", but the point is that it is a stable platform upon which we can build something new without surprises. Just this by itself would be helpful to developers. 2. Develop CommandEvents. Since cE=minimal does very little on its own, we'll have to make it do interesting stuff by listening for events. At first we'll have to listen for the standard keyboard combinations (Cmd-Backspace), but when CommandEvents hit the scene we'll be able to listen for 'deleteToBeginningOfLine'. This will allow us to make more functional editors with fewer lines of code and fewer bugs. Note that this would benefit both cE=min and cE=true. 3. Improve Selection and Range API and others. Right now there is no sane way for me to know where my content wraps, so it's near impossible to do my own implementation of 'deleteToBeginningOfLine', making it difficult to override. There are many other helpful APIs we could come up with that would help people developing editors, but first we need a stable surface to build on. I think if we start with #1, that will at least put devs in a sane place. Then we can make their lives easier with #2 and #3. I have an idea for what we could do for #1. I'll try to write it up in a separate email. Thank-you for reading. I look forward to discussing this further with everyone. Olivier Forget