- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sun, 25 Jun 2006 03:03:15 -0400
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|.
Received on Sunday, 25 June 2006 00:03:15 UTC