<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 31, 2008, at 12:26 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Jan 1, 2009 at 4:15 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div>2) The proposal Hixie linked seems way overengineered for this purpose. First, it allows spellchecking to be explicitly turned on, potentially overriding normal defaults, but that seems wrong; an <input type="email"> should never spellcheck regardless of the page author says. I can't see any valid use case for the author turning spellchecking on regardless of UA defaults or user preferences.</div> </blockquote><div><br>It allows you to have a region of text where spellchecking is disabled via the spellcheck attribute, but containing subregions where spellchecking is enabled.</div></div></blockquote><div><br></div><div>It seems to me you would have to have a lot of custom code to maintain the boundaries between such regions during editing operations for this to ever work right. Normal text editing would easily lead to text moving across the boundaries. There would have to be strong motivating examples to justify such a hard-to-use feature.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>Second, it allows spellchecking to be controlled at a finer granularity than editability, for which again I think there is no valid use case. Both of these aspects make the feature more complicated to implement and harder to understand, compared to just having a way to only disable spellchecking at the same granularity as editing.<br> </div> </blockquote><div> </div></div>A use case is editable program code, where spellchecking is disabled, but where spellchecking is enabled inside comments. Maybe that sounds a little far-fetched for today's Web applications, but some IDEs (e.g. Eclipse) support this so it seems like something we'd want in the future.<br></blockquote></div><div><br></div><div>This sounds like a pretty ill-conceived feature. It is very common for comments to include code, or fragments of code (such as variable names) mixed with natural language. (I was unable to find any evidence of spellchecking comments in the copy of Eclipse I downloaded, so I can't comment on the details.)</div><div><br></div><div>Furthermore, other IDEs generally don't attempt to do this, and I can't think of other application categories that would do something similar.</div><div><br></div><div>So I don't think this makes for a very compelling use case. It's like arguing for a page layout feature based on something only WordPerfect does.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>