From m_kato at ga2.so-net.ne.jp Tue Mar 1 00:18:57 2011 From: m_kato at ga2.so-net.ne.jp (Makoto Kato) Date: Tue, 01 Mar 2011 17:18:57 +0900 Subject: [whatwg] set input.value when input element has composition string In-Reply-To: <4D6B9593.6020602@w3.org> References: <4D674942.9010804@ga2.so-net.ne.jp> <4D6B9593.6020602@w3.org> Message-ID: <4D6CABF1.1020709@ga2.so-net.ne.jp> Hi, Kang-Hao. On 2011/02/28 21:31, Kang-Hao (Kenny) Lu wrote: > Hello Makoto, > (Cc+ public-webapps) > > (11/02/25 15:16), Makoto Kato wrote: >> Hi, >> >> This is simple sample. This behavior is different on all web browsers >> when input element has composition/preedit string for IME. > A relevant question here, I think, is where the cursor should go when > the value of the text box is set by script. For Safari5, it always goes > to the end when the value is set. For FF4.0b11, the cursor stays in > previous position when the value to be set is the same and goes to the > end when the value is different. Is this a known incompatibility? I find > the behavior of FF quite strange. On Safari 5, even if textbox has IME composition string, text into textbox can be replaced by DOM/script. But other browser's behaviors are different, and this is no specification when textbox has composition string. Although IE, Chrome and Opera keep composition string after value is replaced by DOM, each behavior is different. This is the result for this test on each browsers. When textbox has IME composition string such as ABCDEFG, then script (textbox.value = "123";) is called, textbox becomes... 1. "123ABCDEFG" (ABCDEFG keeps composition state and caret is after G). 2. "123" (composition string is removed). 3. "ABCDEFG" (ABCDEFG keeps composition state and caret is after G). Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is Chrome 10 and IE9. Also, on Firefox/Gecko, since there is some bugs, key input cannot work until IME is turned off. So to fix this, I am talking with Ehsan about right specification. But there is no discussion about this specification/behavior at WHATWG. >> If input element has composition string by IME, should it cancel >> composition string and set value by script? Or should it cancel >> setting value since it has composition string? > What makes sense to me is: > 1. the cursor always goes to the end > 2. the composition string goes with the cursor, which should not change. > > But I am not sure whether this is the right way to go. > > Cheers, > Kenny >> >> >> >> >> >> >> >> -- Makoto Kato >> -- Makoto Kato From robert at ocallahan.org Tue Mar 1 01:13:51 2011 From: robert at ocallahan.org (Robert O'Callahan) Date: Tue, 1 Mar 2011 22:13:51 +1300 Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ? In-Reply-To: References: Message-ID: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai wrote: > FWIW, chromium is planning on experimenting with disallowing modal dialogs > during the beforeunload/unload events. > http://code.google.com/p/chromium/issues/detail?id=68780 > That sounds fairly unpleasant for users of pages which give "are you sure you want to leave this page and lose your data?" warnings. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11] From Alexandre.Morgaut at 4d.com Tue Mar 1 01:37:23 2011 From: Alexandre.Morgaut at 4d.com (Alexandre Morgaut) Date: Tue, 1 Mar 2011 10:37:23 +0100 Subject: [whatwg] 7.3 Timers In-Reply-To: <4D6BF535.3050000@mit.edu> References: <8660AAC8-385E-453C-B180-15FCACB4CB4E@4d.com> <4D6BF535.3050000@mit.edu> Message-ID: <93155C1E-A37E-4445-84DF-A089713BCEE0@4d.com> On Feb 28, 2011, at 8:19 PM, Boris Zbarsky wrote: >> But well, the signature looks like there is only one parameter > > No. If there were only one parameter, the signature would say |in any > args|. It actually says |in any... args| which means any number of > arguments. See http://www.w3.org/TR/WebIDL/#dfn-variadic-operation Thanks for highlighting that, I see it more clearly By the way I still don't see it in the process, I only see: - the "get the timed task handle" step - and the "get the timeout" step >> But couldn't setTimeout() accept natively a Date object in place of the timeout parameter > > Note that if you set a timeout for 1 hour from now, and then the > computer goes to sleep for 3 hours, then the timeout will fire 1 hour > after the computer wakes up, not immediately on wakeup. I agree this is a problem for the listed use cases This is another good reason: - to use a different method name for this purpose - to provide a better solution to these needs I'm not sure which one could be either correct and intuitive - scheduleTask() ? - setTaskDate() ? - setCron() ? anything else ? The question would be, if the computer goes to sleep, should the user agent : 1 - wake up the computer to execute the function ? 2 - wait until it wake up to execute it ? 3 - ignore the handler if its to late ? The choice between options 2 and 3, could be settable as part of the method signature. The first option looks more sensible and in my opinion should require to activate a setting or ask the user to accept for the current domain This show up another requirement As for a Web "Application", User Agents may provide a setting dialog so it could ask to the user to accept a list of option for the application This way, the user won't miss line on top of the page asking authorizations for each ones Example: setDomainSettings( message, required, optional); where "required" and "optional" parameters would expect a list of options to activate including: - geolocation - storage with specific size - crons - allow popup - remember password Thoughts ? Alexandre. From svartman95 at gmail.com Tue Mar 1 02:33:24 2011 From: svartman95 at gmail.com (Bjartur Thorlacius) Date: Tue, 1 Mar 2011 10:33:24 +0000 Subject: [whatwg] Idea for having InputXML Or ClickXML for HTML5+ In-Reply-To: References: Message-ID: On 3/1/11, Narendra Sisodiya wrote: > We can record mouse and keyboard activity in xml. There are many events > which are resolution independent. > for example mouse clicks, button press events . Now suppose you are dealing > with some animation or game or just a slideshow. what you do ? you type some > buttons from mouse or keyboard. Now if you can record the timeline of these > events then we can play back at anytime. IMO, you should record when users advance slides (rather than when users press spacebar, activate their cursor on a specified region, flick their accelometer wand, or wipe their touch touchpad in a given direction). From webmartians at verizon.net Tue Mar 1 06:12:20 2011 From: webmartians at verizon.net (WeBMartians) Date: Tue, 01 Mar 2011 09:12:20 -0500 Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ? In-Reply-To: References: Message-ID: <4D6CFEC4.6000704@verizon.net> For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. As to comment 2, I agree that the various traps put in place are exceptionally annoying. An alternative would be a forced closing via the browser rather than some modification of the behavior of Javascript. That would side step the question of "Have you covered all of the annoying cases (onbeforeunload, on unload, on hide...)?". On 2011-02-28 19:42, Ian Hickson wrote: > On Thu, 25 Nov 2010, Biju wrote: >> 1. Can we deprecate alert(), confirm(), prompt() ? >> At present many web2.0 js libs are providing alternate [and cool >> looking] methods to achieve use cases where we need to use alert(), >> confirm(), prompt(). So do we need those modal dialogs any longer? > Well we can't remove support for them from browsers, since millions of > pages use them. Conformance checkers can't really complain about usage of > those APIs, since they can't easily check JavaScript runtime compliance. > So what would deprecating them mean? > > >> 2. if we are still keeping them, can we disable them in >> onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in >> those events to confuse users, so that they can trap users for little >> longer. > That's not a bad idea. I recommend approaching the browser vendors to see > if they are willing to implement it; if they do, then updating the spec > accordingly would be a no-brainer. > > >> 3. also if we are keeping them, can we add an optional parameter for a >> timeout milliseconds to self dismiss the modal prompt. > What's the use case? > > > On Thu, 25 Nov 2010, Biju wrote: >> In a software application there is no need to have prompt to the user >> if the application is not planning to do any branching after user >> response. >> When we have alert(), it dont give user any choice other than pressing OK >> Hence it not possible to code any branching statement after result of >> user action. (with exception "Press OK after you insert DVD to the >> drive" ) >> >> So only use for alert() I see is not make a delay, that use case can >> be improved if web programmer can provide a default time out. > As you point out in your original e-mail, it seems like this kind of use > case is better handled by Web 2.0 JavaScript libraries. In the medium term > I expect we will introduce a feature to create modal and non-modal in-page > dialogs using markup, so this will likely become moot. > > > On Thu, 25 Nov 2010, Markus Ernst wrote: >> Maybe, instead of your original suggestion, it might be worth thinking >> about making alert()/confirm()/prompt() dialogs styleable via CSS? Then >> those fancy JS lib dialogs would get obsolete, and we had the favour of >> both nice look and support for the special purposes of those dialogs. > This would be a side-effect of the aforementioned markup-based dialogs. > > > On Thu, 25 Nov 2010, Biju wrote: >> The request I put is NOT about whether you can make it PRETTY looking or >> not. The question is about why we are allowing website have something >> which is MODAL (ie, both window modal and tab modal >> https://bugzilla.mozilla.org/show_bug.cgi?id=59314) >> In my opinion a no website should have that much control over user >> interaction. > On Thu, 25 Nov 2010, Nikita Popov wrote: >> That alert()s, prompt()s and confirm()s are window-modal is only an >> implementation issue: Some years ago browsers implemented these prompts >> the most convenient way: By opening a native modal dialog. But right now >> broswer vendors realize that this isn't really the best solution - >> because of DOS attacks and simply because it doesn't make any sense. >> >> And as you already mentioned: Firefox landed tab-modal dialogs a few >> days ago. Opera already had them. Other browsers will follow. > On Thu, 25 Nov 2010, Markus Ernst wrote: >> Opera even provided a "Stop executing scripts" checkbox in the alert() >> dialog for years already, which made it my preferred browser for >> debugging my scripts (handy if you have forgotten an i++ in a loop, and >> placed an alert() inside). > Indeed. > > > On Thu, 25 Nov 2010, Benjamin Poulain wrote: >> The specification deprecates some elements that use to be widely used >> (the elements font, big, center, etc). > Actually it obsoletes them. > > >> Deprecating is only a recommendation for authors to not use the feature. > It's hard to effectively do that with script since there's no good way to > do scripting validation. > From mikko.rantalainen at peda.net Tue Mar 1 06:38:45 2011 From: mikko.rantalainen at peda.net (Mikko Rantalainen) Date: Tue, 01 Mar 2011 16:38:45 +0200 Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ? In-Reply-To: References: Message-ID: <4D6D04F5.90501@peda.net> 2011-03-01 11:13 EEST: Robert O'Callahan: > On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai wrote: > >> FWIW, chromium is planning on experimenting with disallowing modal dialogs >> during the beforeunload/unload events. >> http://code.google.com/p/chromium/issues/detail?id=68780 > > That sounds fairly unpleasant for users of pages which give "are you sure > you want to leave this page and lose your data?" warnings. We already have onbeforeunload that almost does the trick... How about adding a new property for this that needs to be set before user tries to unload the page in the first place. For example: window.onbeforeunloadmessage defaults to an empty string and if this property is set to non-empty string, then the UA should prompt this message with buttons "Close anyway" and "Stay on page" (or equivalent) before unloading the document. This allows for following fixes to current unload and onbeforeunload features: - Page script must set this message at the moment the page should not be closed without consideration - UA may display visual clue that a tab should not be closed even before the closing is tried - UA does not need to run any JS code before closing a tab because this is only a string that is either empty or not - UA may disable/stop running JS the moment the user tries to close the tab and continue running JS only if user hits the "Stay on page" button. What do you think? -- Mikko From benrimmington at me.com Tue Mar 1 07:50:26 2011 From: benrimmington at me.com (Ben Rimmington) Date: Tue, 01 Mar 2011 15:50:26 +0000 Subject: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt). In-Reply-To: References: <87C0EC60-A1AE-4068-985E-5FCB219F776A@me.com> <4D6AE340.2090107@mozilla.com> Message-ID: <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> On 28 Feb 2011, at 17:52, Bjartur Thorlacius wrote: > Can't we extend the existing window.status? > It's supported by some older UAs (and ignored by others, because of > confusing UI), but if the UI distinguishes page messages from browser > and system messages, it's usable (aside from a historical API, but if > browsers ignore setting the window.status to the empty string). The window.status property [1] doesn't seem to be in the WHATWG HTML spec, I could only find the window.statusbar.visible property [2]. But I doubt that any mobile UAs have a status bar, and it's also hidden by default on Mac OS X Safari (and possibly other desktop UAs as well). However, some mobile platforms have a local notification service [3] [4] [5] [6]. A new window.notify() function might be useful, so that a background card/tab/window can display a message to the user. (Unfortunately, iOS currently uses a modal dialog for its UILocalNotification service. A better implementation might be to put a Notification Center icon in the multitasking UI, similar to the Print Center [7] used by AirPrint.) [1] [2] [3] [4] [5] [6] [7] "Figure 6-4" and "Figure 6-5" From jgraham at opera.com Tue Mar 1 07:58:44 2011 From: jgraham at opera.com (James Graham) Date: Tue, 01 Mar 2011 16:58:44 +0100 Subject: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt). In-Reply-To: <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> References: <87C0EC60-A1AE-4068-985E-5FCB219F776A@me.com> <4D6AE340.2090107@mozilla.com> <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> Message-ID: <4D6D17B4.4060708@opera.com> On 03/01/2011 04:50 PM, Ben Rimmington wrote: > However, some mobile platforms have a local notification service [3] > [4] [5] [6]. A new window.notify() function might be useful, so that > a background card/tab/window can display a message to the user. See [1] for the current state-of-play in giving access to system notification mechanisms. [1] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html From svartman95 at gmail.com Tue Mar 1 09:39:59 2011 From: svartman95 at gmail.com (Bjartur Thorlacius) Date: Tue, 1 Mar 2011 17:39:59 +0000 Subject: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt). In-Reply-To: <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> References: <87C0EC60-A1AE-4068-985E-5FCB219F776A@me.com> <4D6AE340.2090107@mozilla.com> <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> Message-ID: On 3/1/11, Ben Rimmington wrote: > On 28 Feb 2011, at 17:52, Bjartur Thorlacius wrote: > >> Can't we extend the existing window.status? >> It's supported by some older UAs (and ignored by others, because of >> confusing UI), but if the UI distinguishes page messages from browser >> and system messages, it's usable (aside from a historical API, but if >> browsers ignore setting the window.status to the empty string). > > The window.status property [1] doesn't seem to be in the WHATWG HTML spec, I > could only find the window.statusbar.visible property [2]. > > But I doubt that any mobile UAs have a status bar, and it's also hidden by > default on Mac OS X Safari (and possibly other desktop UAs as well). > > However, some mobile platforms have a local notification service [3] [4] [5] > [6]. A new window.notify() function might be useful, so that a background > card/tab/window can display a message to the user. > > (Unfortunately, iOS currently uses a modal dialog for its > UILocalNotification service. A better implementation might be to put a > Notification Center icon in the multitasking UI, similar to the Print Center > [7] used by AirPrint.) I meant to suggest displaying strings assigned to (the unstardandized property) window.status, supported by some browsers, using e.g. methods described in your post. From benrimmington at me.com Tue Mar 1 09:04:50 2011 From: benrimmington at me.com (Ben Rimmington) Date: Tue, 01 Mar 2011 17:04:50 +0000 Subject: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt). In-Reply-To: <4D6D17B4.4060708@opera.com> References: <87C0EC60-A1AE-4068-985E-5FCB219F776A@me.com> <4D6AE340.2090107@mozilla.com> <640025AB-CDC3-424B-8943-F5EB8B12DC84@me.com> <4D6D17B4.4060708@opera.com> Message-ID: On 1 Mar 2011, at 15:58, James Graham wrote: > On 03/01/2011 04:50 PM, Ben Rimmington wrote: > >> However, some mobile platforms have a local notification service [3] >> [4] [5] [6]. A new window.notify() function might be useful, so that >> a background card/tab/window can display a message to the user. > > See [1] for the current state-of-play in giving access to system notification mechanisms. > > [1] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html Thanks for the link. The "Web Notifications" spec doesn't mention a mailing list -- I assume that should be used. P.S. I've just found a good summary of mobile Web technologies: From soyhobo at gmail.com Tue Mar 1 10:30:58 2011 From: soyhobo at gmail.com (usuario) Date: Tue, 1 Mar 2011 18:30:58 +0000 Subject: [whatwg] wrapper element In-Reply-To: <1298919521.3097.6.camel@localhost.localdomain> References: <56E061E7D2A24D21A07EC1DD40964334@JukanPC> <1298919521.3097.6.camel@localhost.localdomain> Message-ID: [resending reply, sorry again with problems] My idea of wrapper or content was to identify actual content from the rest of the window space. Like
actual content centered at 960px
Thanks, I hope i can still contribute to the list, even if my thoughts seem odd. 2011/2/28 Ashley Sheridan > On Mon, 2011-02-28 at 18:46 +0000, usuario wrote: > > [Had problems sending my mails to the list, resending message] > > Some of you may be questioning why a wrapper element if it has not > semantics, the thing is, It DO have semantics. > > Wrapper: > a container element whose solely purpose is to isolate flow content for > visually appealing purposes. It it usually used for applying margin, padding > to inner elements, and dimensionally separating them from its real parent. > > *example, consider:* > >
>
>

Header 1

>

this content is centered because margin: 0 auto is applied to > parent of div.wraper element

> I have always worked, I'm almost standard, sometimes people don't > call me wraper but 'container' or 'content' instead >
>
> > *Against:* > >
> >

Header 1

>

this content is centered because margin: 0 auto is applied to > parent of wrapper element

> I think I'm more semantic because I'm specifically designed for this > task, and I do it very well. What do you think? > >
> > Moreover. > > > Why not borrow the from SVG (meaning "to group together" -- the > > semantics may be a bit more accessible in some cross-linguistic sense than > > , particularly because of the silent "w" in "wrap" which throws a lot > > of folks for a loop)? > > > > Don't know if that's the solution, i just don't discard it. > > > >
carries no semantic meaning. * If you are using it for such, the > > semantic is purely internal to your application*, and thus doesn't > > carry the common meaning of "semantics" as used on the web. > > > > We have no problems with
definition. But i think you are not right in > your statement. > Answer this, Are wrappers purely internal to my(of mine) application? that's > a capitalized lie, just think on it. Most applications use a wrapper-like > div. You had, and i don't know you. > > We have to start deciding what do we want from html5, at what degree do we > want a more semantic web? why just
, why just