Re: [whatwg] Spellchecking proposal #2
Matthew Paul Thomas wrote: On Jun 25, 2006, at 11:59 PM, Lachlan Hunt wrote: Matthew Paul Thomas wrote: ... But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. ... I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. The problem is not with which GUI controls you choose; it's with the amount of attention demanded by the underlying situation. Spellchecking would seemingly be turning itself off for a completely non-obvious reason; and to make it obvious, you would have to make the spellchecking feature more prominent than its importance permits. That would happen with either the author specified attribute approach, or the heuristics approach where browsers make an educated guess based on the semantics and surrounding content. The only way that wouldn't happen is if spell checking was completely controlled by the user, so that it remains in the state it was last set to for all controls; or defaults to being either on or off for every control, regardless of what the user last specified. In thpse cases, it's arguably more important for the spell checking control to be more prominent in the UI. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: Check spelling: ( ) Never (*) As the page author suggests ( ) Always But that really brings out the foolishness of the idea. I can imagine a user looking at that option and thinking Duh - how on earth is the page author ever going to know when and how I want spelling checked? What use cases did we come up with where there might be a textfield or textfield type=text/plain where having spell checking always on would cause problems? Surely the worst that could happen would be some inappropriate red squiggly underlines. Hardly a disaster. Gerv
Re: [whatwg] Spellchecking proposal #2
Gervase Markham wrote: Alexey Feldgendler wrote: Check spelling: ( ) Never (*) As the page author suggests ( ) Always This isn't actually strictly necessary at all - one can imagine the setting being on a per field basis with the author value representing the default and the user being able to choose via the context menu (Firefox has a similar system to this but it doesn't seem to remember your selection between page visits). Of course it's less obvious how this would override the DOM method so a sufficiently determined author could reset all the values every few ms using a timer. But that really brings out the foolishness of the idea. I can imagine a user looking at that option and thinking Duh - how on earth is the page author ever going to know when and how I want spelling checked? What use cases did we come up with where there might be a textfield or textfield type=text/plain where having spell checking always on would cause problems? Surely the worst that could happen would be some inappropriate red squiggly underlines. Hardly a disaster. The only sensible use case that has been suggested so far is for online email apps which allow 1 email addresses in an input type=text - in this case none of the text will be recognized by the spellchecker vs. an input type=text which contains an email subject line, which should be spellchecked.
Re: [whatwg] Spellchecking proposal #2
James Graham wrote: The only sensible use case that has been suggested so far is for online email apps which allow 1 email addresses in an input type=text - in this case none of the text will be recognized by the spellchecker vs. an input type=text which contains an email subject line, which should be spellchecked. How about a scheme where the UA never spellchecks input type=text? Those who have sufficient trouble with spelling a single sentence (the subject line) can right-click and choose Check Spelling? If this whole attribute rigmarole is merely about trying to distinguish between an input type=text containing email addresses and one containing a subject line, then it seems like a storm in a teacup to me. Either people have to manually request it for subject lines, or the email addresses get red squiggly underlines - deal with it. :-) Gerv
Re: [whatwg] Spellchecking proposal #2
On Jun 25, 2006, at 11:59 PM, Lachlan Hunt wrote: Matthew Paul Thomas wrote: ... But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. ... * Status bar icon/text that indicates if spell checking is on or off, and if on, whether or not there are any errors (similar to that found in Microsoft Word). * Toolbar button used to toggle spell checking on or off and indicate it's state. * Context menu item (Opera already has this) * Floating toolbar that displays (possibly docked to one side of the text area) when the textarea has focus, with buttons for things like: spell checking, find and replace, cut, copy, paste, etc. Okay, I should have said any interface for doing that will be either absurd, or so invisible as to make the feature seem like random flakiness. Though commendable, your first and third suggestions are the latter; your second and fourth, and Alexey's attempt, the former. I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. The problem is not with which GUI controls you choose; it's with the amount of attention demanded by the underlying situation. Spellchecking would seemingly be turning itself off for a completely non-obvious reason; and to make it obvious, you would have to make the spellchecking feature more prominent than its importance permits. Perhaps a useful analogy: HTML5 is about making Web applications easier, and in Web applications dataloss often results from going back to previous pages, so there should be a backbuttonallowed= attribute that can be set to false for the html element. And we'll let the user easily override it if they want to. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Spellchecking proposal #2
Anne van Kesteren wrote: Quoting Gervase Markham [EMAIL PROTECTED]: If this whole attribute rigmarole is merely about trying to distinguish between an input type=text containing email addresses and one containing a subject line, then it seems like a storm in a teacup to me. Either people have to manually request it for subject lines, or the email addresses get red squiggly underlines - deal with it. :-) So Google is using a textarea for email addresses. They can work around this by using the repetition features in Web Forms 2.0: | table | tr id=order repeat=template repeat-start=1 | td |select name=email[order].type | optionTo:/option | optionCc:/option | optionBcc:/option |/select | /td | td |input type=text name=email[order].address pattern=[email] | /td | tdbutton type=removeRemove/button/td | /tr | /table | pbutton type=add template=orderAdd Email Address/button/p (Note: Replace [email] above with a valid pattern value for email.) Are email addresses common enough for an email type??? They seem pretty common to me, but we might be overloading the |type| attribute a bit if we add a new value that's so close to being text. Also, that doesn't help the above scenario, because I think Google allows names from an address book in the place of addresses.
Re: [whatwg] Spellchecking proposal #2
Anne van Kesteren wrote:
So I'm not sure about using CSS or XBL, but I do see a need coming
back where you can simple do:
foo { spellcheck:on; content:html-snippet }
... or something like that and have it globally declared for _every_
page that uses the property sheet instead of on every single element.
Of course, the question is when doing such a thing: Where do you stop?
More terrifying is the idea that separate individuals may be
responsible for the CSS and the HTML. The person responsible for the
site style sheets could disable or enable spell checking without the
author of a specific page ever knowing.
Personally, I find the idea of spell checking with |contenteditable|
a bit scary. It strikes me as clashing with the styling of the page.
You'd actually have a case for a :misspelled pseudo-class if this came
into being.
Well, pseudo-element ;-)
Correct, because the spelling region doesn't necessarily correspond
to a single complete element, so it's more like ::selection. The
disturbing thought, though, is that such a pseudo-element would style a
page differently given the same user input because the spell checking
may not work the same across user agents.
[Why] not let the browser vendors determine what
suites their needs on this issue.
Actually, since interoperability isn't necessarily an issue here, you
may be on to something. Perhaps we shouldn't bother to specify how to
deal with spell checking beyond unavoidable interactions.
Care to elaborate? As in, what would be the impact on the proposal?
The impact would be to abandon |spellcheck| as a standard and define
how attributes like |accept| and |pattern| may affect spell checking for
a UA. The only non-user-hostile use for a spellcheck-type attribute
would be to give hints for previously unknown fields, and that could
probably be done with |accept|.
Re: [whatwg] Spellchecking proposal #2
On Jun 24, 2006, at 17:02, Lachlan Hunt wrote: I could easily imagine authors wanting to disable spell checking simply because the squiggly red underlines clash with their site's colour scheme. One way to deal with that problem is to ship browsers with spell checking turned off. Web authors are more likely to focus their efforts of defeating features that are on by default. The user could then turn on spell checking everywhere. It isn't disastrous if the spell checker occasionally draws a squiggly line under something that doesn't need to be checked. (Unless, of course, the user is really clueless and cannot judge whether spell checker results require action or not. Sadly, those users exist.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Spellchecking proposal #2
Quoting Matthew Raymond [EMAIL PROTECTED]:
So I'm not sure about using CSS or XBL, but I do see a need coming
back where you can simple do:
foo { spellcheck:on; content:html-snippet }
... or something like that and have it globally declared for _every_
page that uses the property sheet instead of on every single element.
Of course, the question is when doing such a thing: Where do you stop?
More terrifying is the idea that separate individuals may be
responsible for the CSS and the HTML. The person responsible for the
site style sheets could disable or enable spell checking without the
author of a specific page ever knowing.
May be I wasn't clear. I was not proposing more properties to CSS.
Having a separate language that can take care of the more behavioral
things that are easily expressed.
The impact would be to abandon |spellcheck| as a standard and define
how attributes like |accept| and |pattern| may affect spell checking for
a UA. The only non-user-hostile use for a spellcheck-type attribute
would be to give hints for previously unknown fields, and that could
probably be done with |accept|.
I think people would give wrong values for accept in such cases just
to turn it off/on.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Spellchecking proposal #2
Matthew Paul Thomas wrote: On Jun 25, 2006, at 2:02 AM, Lachlan Hunt wrote: ... However, the proposed spellcheck attribute has one major advantage over all of those: it's being designed to allow the user to easily override it if they want to. But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. For example, in Opera: | Select all #A | || | Check spelling| | Really check spelling | || What's the point of the separate Really check spelling item? If spell checking is turned on for the text field, the browser could check the Check spelling entry, and leave it unchecked if it's turned off. But there's far more creative things that browsers can do, browser UIs are continually improving and there's nothing stopping a browser from implementing an improved UI for it. For example, here's a few ideas that browsers could implement: * Status bar icon/text that indicates if spell checking is on or off, and if on, whether or not there are any errors (similar to that found in Microsoft Word). * Toolbar button used to toggle spell checking on or off and indicate it's state. * Context menu item (Opera already has this) * Floating toolbar that displays (possibly docked to one side of the text area) when the textarea has focus, with buttons for things like: spell checking, find and replace, cut, copy, paste, etc. I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. We just have to look past pre-existing bad user interfaces and think outside the box a little. I'm starting to think we just need to define the attribute in a way that is semantic, and possibly come up with a new name to match. And also give non-normative guidelines about how other attributes may be used to improve the logic. For instance, the attribute could be defined like this: | The |on| value indicates that the expected user input will | primarily comprise natural human language. The off value | indicates that the expected user input will not. If the | attribute is not specified, user agents are free to use any | algorithm they like in order to determine the type of the | expected user input. | | User agents may use this to determine whether or not to | provide spell checking for the content by default. User | agents should provide a way for the user to override this | decision. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Hi, Ian,
I'd be happy without the attribute at all, but Mozilla is going to have
something to enable/disable this feature from markup, and they wanted to
have a spec for it so they asked WHATWG to provide a strawman. I figure
it's better to have a spec and an implementation than just an
implementation...
My 2 cents:
Spellchecker looks like pure behavioral entity.
So I would define this as:
style
#myeditor
{
white-space:pre; overflow: auto; ...
behavior: textarea spellchecker; /* textarea editor and spellchecker
*/
}
/style
In htmlayout engine each DOM element can have
multiple behaviors assigned, so following:
textarea id=myeditor.../textarea
will behave as a text area editor with spellchecker using
style declaration above.
(in fact behavior:textarea and/or spechecker can be assigned to
any DOM element with display-role: block, (not only textarea)
but this is another story)
Andrew Fedoniouk.
http://terrainformatica.com
- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: David Hyatt [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 5:42 PM
Subject: Re: [whatwg] Spellchecking proposal #2
On Thu, 22 Jun 2006, David Hyatt wrote:
If the user wants spell checking on in all textareas, then it should be
on,
regardless of what the page says. I don't think the page should be
allowed to
override spell checking rules, since this is really a user decision.
Agreed; the spec is written so as to allow the UA to always honour the
user prefs instead of the author hints if desired.
For example, I know how to spell, so I don't want spell checking on in
any controls. A person with poor spelling, however, might want spell
checking on in all controls. I think it's totally inappropriate for a
Web page to have any control over spell checking settings.
Some sites want to hint to the UA that for certain form controls there is
no point enabling spellchecking (e.g. because they contain a list of
e-mail addresses or some such), whereas for others they would recommend it
be enabled (forum comment boxes or some such).
I'd be happy without the attribute at all, but Mozilla is going to have
something to enable/disable this feature from markup, and they wanted to
have a spec for it so they asked WHATWG to provide a strawman. I figure
it's better to have a spec and an implementation than just an
implementation...
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking proposal #2
Andrew Fedoniouk wrote:
Spellchecker looks like pure behavioral entity.
Behavior is generally handled exclusively by Javascript, but some
people have expressed that having to use script to enable spell checking
is highly undesirable.
So I would define this as:
style
#myeditor
{
white-space:pre; overflow: auto; ...
behavior: textarea spellchecker; /* textarea editor and spellchecker
*/
}
/style
In htmlayout engine each DOM element can have
multiple behaviors assigned, so following:
textarea id=myeditor.../textarea
will behave as a text area editor with spellchecker using
style declaration above.
(in fact behavior:textarea and/or spechecker can be assigned to
any DOM element with display-role: block, (not only textarea)
but this is another story)
This looks a lot like an HTML Control (HTC), but it's incorrect if it
is. Remember that binding mechanisms like HTC and XBL are for binding
HTML/CSS/Javascript to elements, so any solution provided by those
mechanisms would have to have support in one of those languages.
However, I suspect this is supposed to be a means of using canned
styles built into the browser. While this may be useful is some cases,
there is a danger that this could lead to people trying to reimplement
(X)HTML using CSS/XBL.
Re: [whatwg] Spellchecking proposal #2
On Sun, 25 Jun 2006 12:16:09 +0700, Matthew Paul Thomas [EMAIL PROTECTED] wrote: But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. Not necessarily. Check spelling: ( ) Never (*) As the page author suggests ( ) Always -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
On Saturday 2006-06-24 11:45 +0700, Alexey Feldgendler wrote: IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. I agree, but for a different reason. The problem with heuristics is not that they might be better in some browsers and worse in others. The problem is that heuristics are only heuristics when they operate on input written without knowledge of the heuristics. When the input was written with knowledge of the heuristics, they become de facto standards. In other words, authors will figure out what the heuristics are and then write markup to match the heuristics rather than to match the semantics of their content. Authors will learn what triggers spellchecking (or not) in Mozilla, and write whatever markup, however inappropriate, gives the choice of spellchecking that they want. Then other browsers will be forced to copy whatever Mozilla did. So if we're going to end up with a standard anyway, why not admit it and figure out what it should be rather than ending up there accidentally? -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpp9ZvKOeoW7.pgp Description: PGP signature
Re: [whatwg] Spellchecking proposal #2
On Sat, 24 Jun 2006 12:27:33 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Once again, a CSS/XBL based approach would be better here. I do not understand what you mean by a CSS/XBL approach in this context. Moving the spellchecking control out of HTML into CSS or XBL binding. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
+1 I've read this discussion,but i do not understand exactly why this should be denoted in markup.i do not understand why it is needed anyway.is the lang attribute not sufficient? what about denoting every paragraph in a document should be spellchecked,and denoting every del not? what do spellchecking attributes say about the structure of the document?why not let the browser vendors determine what suites their needs on this issue. On Sat, 24 Jun 2006 12:27:33 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Once again, a CSS/XBL based approach would be ere. I do not understand what you mean by a CSS/XBL approach in this context. Moving the spellchecking control out of HTML into CSS or XBL binding. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: I'd say that if the user has globally disabled spellchecking, the author should not be able to override this. However, author's ability to explicitly disable spellchecking on some elements is meant to improve usability. I might be persuaded to allow an author to specify whether or not to enable spell checking in the event that the user has not specified the setting themselves for a specific type of input field. However, if, for instance, you enable spell checking for address fields, the author should not be able to turn it off. Furthermore, the user shouldn't have to know CSS or HTML in order to configure spell checking preferences.
Re: [whatwg] Spellchecking proposal #2
[EMAIL PROTECTED] wrote: On Sat, 24 Jun 2006 12:27:33 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Once again, a CSS/XBL based approach would be ere. I do not understand what you mean by a CSS/XBL approach in this context. Moving the spellchecking control out of HTML into CSS or XBL binding. +1 I've read this discussion, but [I] do not understand exactly why this should be denoted in markup. One could argue that |spellcheck| is behavioral, in which case it should actually be in JavaScript and/or DOM. CSS is presentation only, and XBL is for binding to additional CSS, HTML and Javascript, not for providing semantics, behavior or presentation directly. [I] do not understand why it is needed anyway. [Is] the lang attribute not sufficient? No, because having a blank |lang| is abusive and confusing. What happens if someone put |lang=| in an element and meant to specify the language, but forgot? Besides, setting |lang| on an HTML control may mean that the default content is in that language rather than the control accepting input in that language. Also, there's nothing intuitive about |lang=| turning off spell checking, so you would not normally assume that it would do so if you saw it in the markup. Furthermore, |lang=| may be present in legacy markup. [What] about denoting every paragraph in a document should be spell checked, and denoting every del not? Personally, I find the idea of spell checking with |contenteditable| a bit scary. It strikes me as clashing with the styling of the page. You'd actually have a case for a :misspelled pseudo-class if this came into being. [What] do spell checking attributes say about the structure of the document? About document _structure_? Absolutely nothing. [Why] not let the browser vendors determine what suites their needs on this issue. Actually, since interoperability isn't necessarily an issue here, you may be on to something. Perhaps we shouldn't bother to specify how to deal with spell checking beyond unavoidable interactions.
Re: [whatwg] Spellchecking proposal #2
Quoting Matthew Raymond [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
On Sat, 24 Jun 2006 12:27:33 +0700, Lachlan Hunt
[EMAIL PROTECTED] wrote:
Once again, a CSS/XBL based approach would be ere.
I do not understand what you mean by a CSS/XBL approach in this
context.
Moving the spellchecking control out of HTML into CSS or XBL binding.
+1
So I'm not sure about using CSS or XBL, but I do see a need coming
back where you can simple do:
foo { spellcheck:on; content:html-snippet }
... or something like that and have it globally declared for _every_
page that uses the property sheet instead of on every single element.
Of course, the question is when doing such a thing: Where do you stop?
I've read this discussion, but [I] do not understand exactly
why this should be denoted in markup.
One could argue that |spellcheck| is behavioral, in which case it
should actually be in JavaScript and/or DOM. CSS is presentation only,
and XBL is for binding to additional CSS, HTML and Javascript, not for
providing semantics, behavior or presentation directly.
Following that argument you really need something like the above. You
don't want to have to declare for every element _through scripting_
whether or not spellcheck is on. Doing that you probably get all this
`window.onload = foo;` workarounds with some function that sets all
the relevant default properties. Except that doesn't work, as
sometimes you start typing before the document has completely loaded
(or the DOM is complete) etc.
[I] do not understand why it is needed anyway.
[Is] the lang attribute not sufficient?
The problem with doing that is that authors would set lang= to a
certain value not because the content is in that language, but because
the UA decides spellchecking upon it. That's just wrong.
Personally, I find the idea of spell checking with |contenteditable|
a bit scary. It strikes me as clashing with the styling of the page.
You'd actually have a case for a :misspelled pseudo-class if this came
into being.
Well, pseudo-element ;-)
[Why] not let the browser vendors determine what
suites their needs on this issue.
Actually, since interoperability isn't necessarily an issue here, you
may be on to something. Perhaps we shouldn't bother to specify how to
deal with spell checking beyond unavoidable interactions.
Care to elaborate? As in, what would be the impact on the proposal?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Spellchecking proposal #2
L. David Baron wrote: The problem is that heuristics are only heuristics when they operate on input written without knowledge of the heuristics. When the input was written with knowledge of the heuristics, they become de facto standards. Authors will learn what triggers spellchecking (or not) in Mozilla, and write whatever markup, however inappropriate, gives the choice of spellchecking that they want. Then other browsers will be forced to copy whatever Mozilla did. Theoretically, if the heuristics are written well enough, such that authors providing accurate information end up with the best usability by default, that shouldn't happen. If the heuristics are so bad that authors are left with little choice but to lie to improve the usability, then, yes, we'd end up with exactly that problem. However, in reality, I'd have to admit that such good heuristics are going to take a long time to research and develop well; and, especially in the early stages, probably won't be accurate enough for authors to rely on all the time. So if we're going to end up with a standard anyway, why not admit it and figure out what it should be rather than ending up there accidentally? Yes, I'd rather come up with a less-harmful solution now, regardless of semantic purity, than to repeat the mistakes of the past again and ending up with a more harmful defacto standard. The main problem with providing an explicit spell checking switch to the author is the potential for abuse. History has shown that authors will attempt to disable anything they don't like for any reason whatsoever, regardless of the usability benefits such features provide for users. We've seen that already with all of the following: * IE's smart tags: meta name=MSSmartTagsPreventParsing content=True * Google AutoLink (Some scripts were developed to workaround this) * IE's image toolbar: meta http-equiv=imagetoolbar content=no and img gallery=no) * AutoComplete (autocomplete=off) * Context menus (JavaScripts intercepting right click) * Showing link URLs in status bar (using window.status) * Removing browser chrome (in popups) * View Source (includes attempts to obfuscate source code with JS, disabling context menus, etc.) * Disabling printing (Some JS, works in IE only) * Disabling Save As..., (Some JS, works in IE only) * Disabling caching * And anything else they can get their grubby little hands on! I could easily imagine authors wanting to disable spell checking simply because the squiggly red underlines clash with their site's colour scheme. However, the proposed spellcheck attribute has one major advantage over all of those: it's being designed to allow the user to easily override it if they want to. I'd expect the result of that to be that authors won't bother doing so, unless spell checking really isn't suitable for the expected input, and it's an edge case where browser heuristics typically guess wrongly. I'd like to see some research done to find out exactly what kinds of input authors use input type=text, texarea and contenteditable for, beyond those already mentioned earlier in the thread. I'd also like to see research into the labels, name=, id= and other identifying information, commonly given to such fields, which can be used for developing heuristics. Although accept= is unlikely to be commonly used for textual input these days, it would be useful to see research into the kind of text-based content commonly entered (for which MIME types exist) that browsers could use to improve their spell checking logic (e.g. ignoring elements and attributes in textareas accepting text/html or XML). -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
On Sat, 24 Jun 2006 15:14:02 +0700, [EMAIL PROTECTED] wrote: +1 I've read this discussion,but i do not understand exactly why this should be denoted in markup.i do not understand why it is needed anyway.is the lang attribute not sufficient? It's not sufficient because the lang attribute cannot be used to disable spellchecking. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
On Sat, 24 Jun 2006 16:26:19 +0700, Matthew Raymond [EMAIL PROTECTED] wrote: I might be persuaded to allow an author to specify whether or not to enable spell checking in the event that the user has not specified the setting themselves for a specific type of input field. However, if, for instance, you enable spell checking for address fields, the author should not be able to turn it off. Furthermore, the user shouldn't have to know CSS or HTML in order to configure spell checking preferences. If something can be controlled via user CSS, it doesn't mean that the user necessarily has to know CSS. The user agent can provide GUI to configure some essential overrides -- something like what Opera does for hyperlink styles. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
Quoting Ian Hickson [EMAIL PROTECTED]: The only time spell checking matters is when the user is the one creating the content (not the author). It doesn't make any sense to spell check non-editable content that the user didn't even create. If the content is editable, then spell checking should just be left up to the preference of the user who is editing the content. I really don't see the point of this feature being included in markup. If Mozilla wants it, fine, but I don't think it should be in HTML5. Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? By having something like type=email for multiple e-mail addresses? (Or reusing type=email in some way would work as well I suppose.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Spellchecking proposal #2
Le 22 juin 2006 à 12:04, Ian Hickson a écrit : UAs should use the language of the element to determine what spelling and grammar rules to use. (Language information can come from the lang and xml:lang attributes, Content-Language HTTP headers, or other sources. q.v.) Maybe having the possibility to set the lang attribute to a value meaning not a language would be enough to disable spellchecking when the content isn't a human language. And if you want to explicitly tell a field to use spellcheck you'd use any valid language code, or the empty string which currently mean unknown language. Would this make sense? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Spellchecking proposal #2
Matthew Raymond wrote: Another problem is |pattern|. Any spell checking mechanism will have to conform to the pattern value provided, which means either a really creative spell checking algorithm or turning spell checking off. I think the latter is probably the best idea, but it probably shouldn't be must. These are all the attributes that a spell checker will have to take into account: * type (can only spellcheck type=text) * accept (known MIME types should make spell checking more intelligent) * disabled * readonly * inputmode (maybe?) * list (if entered value is in datalist) * pattern -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
On Thu, 22 Jun 2006 23:04:51 +0700, Ian Hickson [EMAIL PROTECTED] wrote: All elements can have spellchecking enabled or disabled. UAs may allow the user to set this flag, and may have defaults that vary based and various heuristics or user preferences. Spellchecking can be enabled on an element while its children have it disabled. However, by default, user agents should enable spellchecking for an element if it is enabled for its parent element and not explicitly disabled for the child. Do you mean that there should be some inheritance rules? They are not described in your algorithms. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
On Fri, 23 Jun 2006 06:26:31 +0700, Sander Tekelenburg [EMAIL PROTECTED] wrote: Authors should set the document's language information, to enable user agents to accurately determine which dictionary to use when checking the spelling or grammar of user input. IMO this should should be a must. We're going see truckloads of sites that have spellcheck=on, simply because authoring tools will insert it by default, that don't bother to specify a language. The user-agent will then have to revert to the local default language, which can be a serious problem for all those milions whose default language is something else than the webpage's language and who allow spellcheck to be on. The language to use for spellchecking is, in general, different from the language that the webpage is written in. For example, when entering a blog entry into textarea, the user is more likely to write in his native language, which is also the local default language of his user agent, than in the language which the blogging application's UI is in. Using the local default language seems more appropriate here. Even worse: when entering text in textarea, the user actually has a choice which language to write in. I think the user agent should provide, besides just the control to turn spellchecking on and off, a choice of languages. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
On Fri, 23 Jun 2006 07:24:28 +0700, David Hyatt [EMAIL PROTECTED] wrote: If the user wants spell checking on in all textareas, then it should be on, regardless of what the page says. I don't think the page should be allowed to override spell checking rules, since this is really a user decision. For example, I know how to spell, so I don't want spell checking on in any controls. A person with poor spelling, however, might want spell checking on in all controls. I think it's totally inappropriate for a Web page to have any control over spell checking settings. I'd say that if the user has globally disabled spellchecking, the author should not be able to override this. However, author's ability to explicitly disable spellchecking on some elements is meant to improve usability. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
On Fri, 23 Jun 2006 10:22:34 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: On Fri, 23 Jun 2006 10:22:34 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. Generally, that's true. But since spell checking is only a user agent feature intended for the user (it doesn't affect the page or author in any way) and interoperability between one browser's heuristics and another is not required. Browsers should be allowed to innovate as much as they like so they can come up with the best method that suits their users. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
On Sat, 24 Jun 2006 12:09:41 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. Generally, that's true. But since spell checking is only a user agent feature intended for the user (it doesn't affect the page or author in any way) and interoperability between one browser's heuristics and another is not required. Browsers should be allowed to innovate as much as they like so they can come up with the best method that suits their users. Once again, a CSS/XBL based approach would be better here. Unless something is specified explicitly, the user agent can implement any kind of logic in its default rules. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Spellchecking proposal #2
Strongly agree. :) dave On Jun 23, 2006, at 10:09 PM, Lachlan Hunt wrote: Alexey Feldgendler wrote: On Fri, 23 Jun 2006 10:22:34 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. Generally, that's true. But since spell checking is only a user agent feature intended for the user (it doesn't affect the page or author in any way) and interoperability between one browser's heuristics and another is not required. Browsers should be allowed to innovate as much as they like so they can come up with the best method that suits their users. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: Even worse: when entering text in textarea, the user actually has a choice which language to write in. I think the user agent should provide, besides just the control to turn spellchecking on and off, a choice of languages. Of course the UA can provide such features, it's not up to the spec to document what features a browser can and cannot provide for their users, nor how to determine the user's input language. That is up to the browser. One browser may choose to base it on the lang attribute, another on the user's preferences, or even a combination of both. e.g. if a user has specified in their preferences that they can understand and write English and French. 1. The user visits a page with lang=en, the browser could automatically spell check in English. 2. The user visits another page with lang=fr, the browser spell checks in French. 3. The user visits a page with lang=de. Since the user hasn't indicated that they can understand or write the language, the browser can default to the user's most preferred language (either en or fr). In any case, the UA could always offer the user a way to change it at any time. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
On Thu, 22 Jun 2006, David Hyatt wrote: If the user wants spell checking on in all textareas, then it should be on, regardless of what the page says. I don't think the page should be allowed to override spell checking rules, since this is really a user decision. Agreed; the spec is written so as to allow the UA to always honour the user prefs instead of the author hints if desired. For example, I know how to spell, so I don't want spell checking on in any controls. A person with poor spelling, however, might want spell checking on in all controls. I think it's totally inappropriate for a Web page to have any control over spell checking settings. Some sites want to hint to the UA that for certain form controls there is no point enabling spellchecking (e.g. because they contain a list of e-mail addresses or some such), whereas for others they would recommend it be enabled (forum comment boxes or some such). I'd be happy without the attribute at all, but Mozilla is going to have something to enable/disable this feature from markup, and they wanted to have a spec for it so they asked WHATWG to provide a strawman. I figure it's better to have a spec and an implementation than just an implementation... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking proposal #2
If the user wants spell checking on in all textareas, then it should be on, regardless of what the page says. I don't think the page should be allowed to override spell checking rules, since this is really a user decision. For example, I know how to spell, so I don't want spell checking on in any controls. A person with poor spelling, however, might want spell checking on in all controls. I think it's totally inappropriate for a Web page to have any control over spell checking settings. dave ([EMAIL PROTECTED]) On Jun 22, 2006, at 9:04 AM, Ian Hickson wrote: Based on the fedback recently received about how to do spellchecking in HTML, here's a second proposal that uses an attribute to control it. Comments? (Don't worry about typos and other such minor mistakes.) AUTHOR REQUIREMENTS textarea and input elements may have a new attribute specified, spellcheck. If specified, it must have either the value on or the value off (exactly, case-sensitive). The on value indicates that spellchecking is to be enabled, the off value indicates that spellchecking is to be disabled. If the attribute is omitted, the default value is to use the user preferences. In addition, there is a spellcheck DOM attribute on all elements. On HTMLInputElement and HTMLTextareaElement elements, it returns true if the content attribute is on, false if the attribute is off, and the user's preference if the attribute is not set. On other elements, it also returns the current state of spellchecking for that element, but this is not represented in a content attribute. The attribute may be set to true to enable spellchecking, or false to disable it. On elements other than HTMLInputElement and HTMLTextareaElement, this is only expected to be useful if contenteditable= is used. Authors should set the document's language information, to enable user agents to accurately determine which dictionary to use when checking the spelling or grammar of user input. IMPLEMENTATION REQUIREMENTS All elements can have spellchecking enabled or disabled. UAs may allow the user to set this flag, and may have defaults that vary based and various heuristics or user preferences. Spellchecking can be enabled on an element while its children have it disabled. However, by default, user agents should enable spellchecking for an element if it is enabled for its parent element and not explicitly disabled for the child. If spellchecking is enabled on an element, the UA should indicate spelling and/or grammar errors in text nodes that are direct descendants of the element that the user is able to edit, in attributes of the element that the user is able to edit, and, for elements that are form controls that accept arbitrary text input, in the values of those elements. If spellchecking is disabled, the UA should not indicate spelling or grammar errors for that element's text and values. UAs should use the language of the element to determine what spelling and grammar rules to use. (Language information can come from the lang and xml:lang attributes, Content-Language HTTP headers, or other sources. q.v.) The HTMLElement interface has one new DOM attribute: attribute boolean spellcheck; Every element remembers what its spellcheck DOM attribute was last set to, if it has ever been set. On getting, the spellcheck DOM attribute returns a value as determined by the following algorithm. * If the element is an input element or a textarea element, and the element has a spellcheck content attribute with the exact literal value on, then the DOM attribute must return true. * Otherwise, if the element is an input element or a textarea element, and the element has a spellcheck content attribute with the exact literal value off, then the DOM attribute must return false. * Otherwise, if the element is an input element or a textarea element, then the DOM attribute must return true if spellchecking is enabled on the element, and false otherwise. * Otherwise, the element is neither an input element nor a textarea element. If the DOM attribute has been set, then it must return the value it was last set to. * Otherwise, the element is neither an input element nor a textarea element, and the DOM attribute has never been set. The DOM attribute must return true if spellchecking is enabled on the element, and false otherwise. Setting the DOM attribute has the effect determined by the following algorithm: * If the element is an input element or a textarea element, then the element's spellcheck content attribute must be set to the literal value on if the attribute is being set to the true value, and off otherwise. (This affects the spellchecking of the element, see below.) * Otherwise, the element's spellchecking should be enabled if the DOM attribute is set to the value true, and should be disabled otherwise. On input and textarea elements, setting the spellcheck attribute to the value on
Re: [whatwg] Spellchecking proposal #2
On Thu, 22 Jun 2006, David Hyatt wrote: The only time spell checking matters is when the user is the one creating the content (not the author). It doesn't make any sense to spell check non-editable content that the user didn't even create. If the content is editable, then spell checking should just be left up to the preference of the user who is editing the content. I really don't see the point of this feature being included in markup. If Mozilla wants it, fine, but I don't think it should be in HTML5. Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking proposal #2
The only time spell checking matters is when the user is the one creating the content (not the author). It doesn't make any sense to spell check non-editable content that the user didn't even create. If the content is editable, then spell checking should just be left up to the preference of the user who is editing the content. I really don't see the point of this feature being included in markup. If Mozilla wants it, fine, but I don't think it should be in HTML5. dave ([EMAIL PROTECTED]) On Jun 22, 2006, at 5:42 PM, Ian Hickson wrote: I'd be happy without the attribute at all, but Mozilla is going to have something to enable/disable this feature from markup, and they wanted to have a spec for it so they asked WHATWG to provide a strawman. I figure it's better to have a spec and an implementation than just an implementation... -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Spellchecking proposal #2
Ian Hickson wrote: textarea and input elements may have a new attribute specified, spellcheck. If specified, it must have either the value on or the value off (exactly, case-sensitive). The on value indicates that spellchecking is to be enabled, the off value indicates that spellchecking is to be disabled. If the attribute is omitted, the default value is to use the user preferences. I don't particularly like giving the authors any control over spell checking. For the majority of cases, I think browsers should become smart enough to know whether or not to enable/disable spell checking without any explicit author input, based on various heuristics (as I've written about before [1]). In other words, for most cases, authors should not need to use this attribute. UAs may allow the user to set this flag, and may have defaults that vary based and various heuristics or user preferences. That's good, but it really should be a *should* or a *must*. Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? Ordinarily, input type=email would handle no spell checking for email addresses, but given that Gmail uses a textarea that contains both people's names and email addresses, that may be one case where heuristics may not give optimal results. If it were just e-mail addresses, it wouldn't particularly matter because spell checkers can already recognise e-mail addresses and not mark them as errors. But in this case (and others like it), the user should be able to very easily disable spell checking and have the browser remember that preference. Do you think that that one small use case is strong enough to warrant the use of a spellcheck attribute? Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? Is it really a major usability issue if a browser enables spell checking for a field where the user wouldn't want it, considering it can be easily disabled (or vice versa)? For contenteditable use cases, roughly what percentage of them would need the author to turn on or off spell checking? Given that the user can add semantics to their content using elements, browsers should be able to enable and disable spell checking for different sections. e.g. if a user starts entering code into a contenteditable section, UAs should be able to automatically disable spell checking for that content, while still checking the surrounding text. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=339127#c7 -- Lachlan Hunt http://lachy.id.au/
