Re: [whatwg] Spellchecking mark III
On Wed, Jan 21, 2009 at 4:51 PM, Aryeh Gregor simetrical+...@gmail.com wrote: In practice, I think the only way to avoid this problem is for browsers to implement content-sniffing techniques of some kind to figure out the language, at least per field but ideally on a word-by-word basis. If the browser is set to spellcheck in English but you start putting in lots of non-Latin characters and every word is therefore misspelled, the browser should be clever enough to try switching the spellcheck language, or at least disabling spellcheck for words that can't possibly be from the language it's checking against. More refined heuristics could detect even subtle differences, like between British and American English, and remember for next time which one the user usually types in. this is approximately what I'm hoping to see implemented for Firefox. I haven't worked on the spell checking code recently, but it's what I feel is necessary having worked in an organization where the default language and the used language don't match. The result is everyone either ignores or turns off spell checking. I'm hoping to either find someone to implement this, or implement it myself. Either way, with this implemented, my employer would eventually update my coworkers' browsers to such a Firefox, and then I can hope they will get more useful feedback and actually pay attention to their typing. -Yes, I'm aware that this is a pipe dream. I need this dream. None of this needs, or even could effectively use, author intervention: 1) The author cannot know what languages users will want to enter in all cases. I've sometimes found myself writing posts in Hebrew on English-only sites, for instance. 2) The author certainly won't be able to determine the dialect or variant of the language the user will want to use, which is necessary for spellcheck. 3) Authors should not have to add extra markup if it's not really necessary, because in practice, most won't. To be as useful as possible, spellcheck should Just Work without explicit author intervention.
Re: [whatwg] Spellchecking mark III
Peter Kasting ha scritto: On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino alex.baldacch...@email.it mailto:alex.baldacch...@email.it wrote: Why not to let the user choose the language, as it happens in word processors? A UA can't choose accurately whether, for instance, color is a correct American English, a wrong British English, or even a correct (truncated) Italian word, while a human can do it better, thus a UA could provide an interface to change the language for a selection spellchecking, or even for each mispelled word, starting from a hint language, which could be the value of an element lang attribute (beside a default value and a user-preference forced one - the latter bypassing any authored value). Also, using the lang attribute value as the start language to check (if not in contrast with a user preference) would allow an interactive interface with a script changing that value according to a user's choice (UAs could also expose a list of supported languages). I'm not sure I fully grasped everything here, but what I did grasp sounds very much like a cross between what Chromium is doing today and what we want to do in the future (I imagine similar things are true for other browser vendors). User specification and page hints are both useful tools for a UA. But I still claim that all of those aspects are outside the scope of the spellcheck attribute, and fall into the realm of things that should not be in the HTML5 spec as they're very much UA-specific behavior. PK Probably. However, establishing that the lang attribute is the first-choice language to check (which wouldn't prevent the UA from providing other choices, or just ignoring such behaviour due to a user preference, or using other dictionaries too -- and that might be suggested in a note on usability, I guess), I mean, would allow a webapp to emulate those functionalities to some extent, just setting a different value for the lang attribute of a contenteditable box and some of its subregions through a script at the user whim (that is, let's do it through script until UAs provided a better solution, which could be hinted by scripting hacks based on the lang and spellcheck attributes working together at the same grane). I think that a control over the language to check can improve spellchecking at the same grane as the spellcheck attribute, whereas it can't harm end users more than a wrong assumption on spellchecking. A user would notice a wrong checking not matching the language he's using, and could disable it or do whatever else a UA allows him to do (though being annoying); on the other hand, a user might not notice spellchecking is disabled on a certain area, and could not beware his errors, unless the UA informed him somehow (about spellchecking being turned off). Therefore, a special care by UAs is needed in both cases, yet both features can improve webapps providing a rich and/or specialized editor (such as a code editor, where disabling spell checking but for comments may make sense), so why not consider both of them, since they're related? Also, implementation and usages experience could suggest whether it is worth to expose UAs' supported languages through DOM APIs (e.g. to allow a webapp to create a dynamic list of checking-available languages, to avoid static lists being either incomplete, or too long and possibly including unsupported languages), and this would affect either the Window or the Navigator interface (or something else in HTML5 scope). Everything, IMHO. WBR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8547d=22-1
Re: [whatwg] Spellchecking mark III
Probably. However, establishing that the lang attribute is the first-choice language to check (which wouldn't prevent the UA from providing other choices, or just ignoring such behaviour due to a user preference, or using other dictionaries too -- and that might be suggested in a note on usability, I guess), I mean, would allow a webapp to emulate those functionalities to some extent, just setting a different value for the lang attribute of a contenteditable box and some of its subregions through a script at the user whim (that is, let's do it through script until UAs provided a better solution, which could be hinted by scripting hacks based on the lang and spellcheck attributes working together at the same grane). I don't think that applications need ability to precisely control spell-checking language. Browser knows best which dictionaries are available, and can auto-detect language based on user's preferences, page's language and text itself. You can expect that browsers will have much more sophisticated and reliable language detection than web apps (that's an area where browsers can freely compete). Many of your suggestions are just implementation details, which HTML shouldn't specify precisely (it could force browsers to use method that is suboptimal). HTML just needs to offer reasonable way to implement good heuristics, and I think existing lang, input types and spellchecking attribute are sufficient. -- regards, Kornel
Re: [whatwg] Caching offline Web applications
On Tue, 18 Nov 2008, Michael Nordman wrote: Fwi, this piece of functionality may warrant some actual consideration. I think this would add very little complexity to the spec and implementations, but would add a great deal of value. Big bang for little buck. Many applications that use Gears depend on the intercept ability in some central fashion. Lets just take an example from Google Docs use of Gears. There are two intercept entries for urls of the form /Doc? and /View?. Doc provides an editable interface. View provides a read-only view. The document id is provided to these pages as a query parameter. Upon loading, these cached pages examine the query params and retrieve the appropiate document data from the an SQL database, and populate the DOM accordingly. This is a fairly common use case from what I've seen. I think the inclusion of a feature along these lines would greatly help existing Gears users migrate to this new system. There are several ways we could solve this problem, and I'm not sure we've yet really come up with the best solution. Concerns have been raised both about solutions like the above and about the dynamic entries feature. Now that I've removed the dynamic entries feature, it will be easier to add a feature such as the above once we have more implementation experience and authoring experience. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Video and Audio schema for validators
I'm trying to add video and audio tags to our XHtmlValidator and after going through http://www.whatwg.org/specs/web-apps/current-work/ I've pieced together schemas for both, but wanted to ask if there was a more authoritative source? In particular, I came across a couple of event handlers in examples that i can't find defined anywhere in the specs, like ondataunavailable and oncanshowcurrentframe Anyway, here's what i've come up with so far, any pointers, corrections, additions would be most welcome (attributes marked with * are considered unsafe, i.e. may contain javascript and should be scrubbed or stripped as appropriate) video: media height poster* width audio : media media : htmlelement autoplay controls currentTime defaultPlaybackRate loop muted playbackRate src* volume onloadstart* onprogress* onsuspend* onload* onabort* onerror* onemptied* onstalled* onplay* onpause* onloadedmetadata* onloadeddata* onwaiting* onplaying* oncanplay* oncanplaythrough* onseeking* onseeked* ontimeupdate* onended* onratechange* ondurationchange* onvolumechange* htmlelement : class contenteditable contextmenu dir draggable id hidden lang style* tabindex title onabort* onblur* onchange* onclick* oncontextmenu* ondblclick* ondrag* ondragend* ondragenter* ondragleave* ondragover* ondragstart* ondrop* onerror* onfocus* onkeydown* onkeypress* onkeyup* onload* onmessage* onmousedown* onmousemove* onmouseout* onmouseover* onmouseup* onmousewheel* onscroll* onselect* onsubmit* thanks, Arne Claassen MindTouch
Re: [whatwg] Ghosts from the past and the semantic Web
On Thu, 28 Aug 2008, James Graham wrote: Henri Sivonen wrote: On Aug 28, 2008, at 15:00, Russell Leggett wrote: I actually think that using custom microformat-like conventions with classes or tags is really not as robust a solution as what is being attempted with RDFa (I honestly did not know much about RDFa before this conversation). However, while people keep suggesting classes, I have yet to hear anyone suggest the data- attributes. Maybe it was said or implied elsewhere, but it seems like a good fit here. Instead of requiring the addition of about or property attributes, just use data-about or data-property. It may not be ideal, but it fits with the existing spec. As Anne and Julian have pointed out, that's not a use of data-* attributes permitted by the spec. FWIW I think we have a problem in that multiple independent people have seen data-* and assumed they are for externally readable metadata. If the bad effects of people using it for that purpose are worse than the usefulness of the feature, we need to consider removing the feature. If the bad effects are not so bad we need to consider legitimizing this as it is clearly something that it is clear will happen irrespective of what the spec says. I've added more text about data-*=. I think the problem will resolve itself. If there are enough use cases for metadata, then we'll add something to HTML5 to support it (e.g. RDFa), thus relieving the pressure on data-*=; if there aren't, then it doesn't matter, since the pressure will be minimal anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video and Audio schema for validators
On Thu, 22 Jan 2009, Arne Claassen wrote: I'm trying to add video and audio tags to our XHtmlValidator and after going through http://www.whatwg.org/specs/web-apps/current-work/ I've pieced together schemas for both, but wanted to ask if there was a more authoritative source? Nope, that's as authoritative as it gets. In particular, I came across a couple of event handlers in examples that i can't find defined anywhere in the specs, like ondataunavailable and oncanshowcurrentframe Yeah the spec right now doesn't do a good job of listing all the event handler attributes. I plan to fix that sometime this year. One thing to note: they'll all be on all elements, not just the media elements. For media, there'll be one event handler per event in the summary table in the media section. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Caching offline Web applications
On Thu, Jan 22, 2009 at 4:34 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Nov 2008, Michael Nordman wrote: Fwi, this piece of functionality may warrant some actual consideration. I think this would add very little complexity to the spec and implementations, but would add a great deal of value. Big bang for little buck. Many applications that use Gears depend on the intercept ability in some central fashion. Lets just take an example from Google Docs use of Gears. There are two intercept entries for urls of the form /Doc? and /View?. Doc provides an editable interface. View provides a read-only view. The document id is provided to these pages as a query parameter. Upon loading, these cached pages examine the query params and retrieve the appropiate document data from the an SQL database, and populate the DOM accordingly. This is a fairly common use case from what I've seen. I think the inclusion of a feature along these lines would greatly help existing Gears users migrate to this new system. There are several ways we could solve this problem, and I'm not sure we've yet really come up with the best solution. Concerns have been raised both about solutions like the above and about the dynamic entries feature. Now that I've removed the dynamic entries feature, it will be easier to add a feature such as the above once we have more implementation experience and authoring experience. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Thnx for the response Ian, much better than months of thundering silence. I'm not yet sure we've come up with solutions that will stand the test of time and merit inclusion in a spec either. Having said that, what is spec'd for AppCache does hang together fairly well. What's there is necessary and useful, but alas... insufficient. Its interesting to see how this functionality has gotten stripped down to the bone, and I'm looking forward to see how it gets built back up to something that is of broader practical use. I seriously doubt if gears customers could actually drop gears and use the HTML5 system as spec'd instead.
Re: [whatwg] Caching offline Web applications
On Thu, 22 Jan 2009, Michael Nordman wrote: Thnx for the response Ian, much better than months of thundering silence. Sorry about that; the appcache feature was on the back burner for a few months as I tried to get through the pile of old feedback. I'm not yet sure we've come up with solutions that will stand the test of time and merit inclusion in a spec either. Having said that, what is spec'd for AppCache does hang together fairly well. What's there is necessary and useful, but alas... insufficient. Its interesting to see how this functionality has gotten stripped down to the bone, and I'm looking forward to see how it gets built back up to something that is of broader practical use. I seriously doubt if gears customers could actually drop gears and use the HTML5 system as spec'd instead. I agree that what we have isn't yet enough for everyone. Hopefully we'll be able to move on to adding these features sooner rather than later. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking mark III
Kornel Lesiński ha scritto: Probably. However, establishing that the lang attribute is the first-choice language to check (which wouldn't prevent the UA from providing other choices, or just ignoring such behaviour due to a user preference, or using other dictionaries too -- and that might be suggested in a note on usability, I guess), I mean, would allow a webapp to emulate those functionalities to some extent, just setting a different value for the lang attribute of a contenteditable box and some of its subregions through a script at the user whim (that is, let's do it through script until UAs provided a better solution, which could be hinted by scripting hacks based on the lang and spellcheck attributes working together at the same grane). I don't think that applications need ability to precisely control spell-checking language. Browser knows best which dictionaries are available, and can auto-detect language based on user's preferences, page's language and text itself. You can expect that browsers will have much more sophisticated and reliable language detection than web apps (that's an area where browsers can freely compete). Browsers can't do better than word processors, which are the state of the art in... word processing. At most, browsers can do as well, and, over some extent, word processors don't use heuristics while you're typing, because no heuristics can guess whether you're *purposedly* switching between dialects (such as British and American English), or if you just mispelled a word (personally, I dislike even the automatic correction of common mistakes in w.p.). Word processors make a choice when you start writing (or before, basing on your installation language, for instance), and let you change it for the whole document or for each single word. I don't think any heuristic auto-detection can be better; instead, no language detection (and users' explicit choice) is more reliable than any sophisticated heuristics. Turning spelling checking on or off makes sense if one can guess how the user agent would behave AND if the user agent can recover misuses, thus I believe that spellcheck is strictly related to the way a spellcheking language is detected and is half of the problem of controlling spellcheking. Otherwise, if it's thought that everything should be under the control of a UA, let's state spellchecking must be always on and peace. Just because being annoyed by a wrong checking (e.g. because the heuristics fails, but it would be the same for a wrong lang value) is less harmful than thinking one's writing correct text because of being unaware that checking has been disabled by the author without asking one's permission. Yet, both lang and spellcheck attributes can be useful for the purpose of controlling spellchecking and improving a web-based word processor, and in both cases UAs can recover from misuses, somehow (e.g. allowing the user to bypass authors' choices). Moreover, I think that interactive and script-aware UAs should act as a framework for web-based applications providing as much of a client-only application functionalities as possible, thus browsers should include new features when possible and reasonable (while trying not to became oversized). I agree that spellchecking is a good feature to support in a browser; I don't see why a web-based rich text editor should be prevented from controlling it on users' behalf, as it happens in word processors, givent it's about to support an existing attribute (lang, which could be stated to be triggering UAs heuristics by default when unspecified for editable elements) and a new one (spellcheck) in conjunction for this purpose (also a list of supported dictionaries would be useful). I also think that features which are not core functionalities for a UA should be provided in a basic version (for general use in web pages) and as building blocks for web applications, not in a complete version under a UA exclusive control (for instance, a UA could allow the user to change the language for some selected text through a context menu option, but the right place for an option allowing a (starting) choice valid for a whole editable element, in a rich text editor, should be the editor interface, which shouldn't be provided by a UA, as a whole or in part, or, if the UA provides it, it should be exposed to any webapp to be customized and enhanced). That's because a specific application can focus on a specific task usability better than its underlying, general purpose framework (like a browser is or should be for a web application). Furthermore, if you agree that a page's language should be used to improve auto-detection, why not to use an element language attribute too? With the benefit that it can be changed dynamically to please the user. Many of your suggestions are just implementation details, which HTML shouldn't specify precisely (it could force browsers to use
Re: [whatwg] Video and Audio schema for validators
On Fri, Jan 23, 2009 at 1:55 PM, Arne Claassen ar...@mindtouch.com wrote: In particular, I came across a couple of event handlers in examples that i can't find defined anywhere in the specs, like ondataunavailable and oncanshowcurrentframe These are probably some of my examples that I wrote back when the spec used to have those. I've not updated the examples on that page to match the current spec. Chris. -- http://www.bluishcoder.co.nz
