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
