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
