Re: [whatwg] input type=text accept=
On Wed, 31 May 2006, James Graham wrote: Ian Hickson wrote: The Mozilla guys propose (in bug 339127) to make the accept= attribute on input elements also apply to types other than type=file, with the same meaning as we currently have on textarea. Their particular use case is to use this as a hook for showing or hiding the spell-check UI. What do people think? Good idea? Bad idea? Sounds like an ideal use-case. The spec should support this. Many other people also replied on this thread. Based on the various feedback, I've backed out from this now and we'll just have an attribute per feature. spellcheck= won't be added to WF2, but it will probably be in HTML5. On Wed, 31 May 2006, Michel Fortin wrote: Since you're reviewing this, I have some issues/commentary to I'd like to put to your attention: * Very often, HTML content in a textarea is just a snippet, not a full document. What should we expect of the content of an input or a textarea with accept=text/html? No idea. We need implementation experience. * Going a little further, should there be a way to tell which elements are allowed and which are disallowed within an HTML snippet? I suppose it may complicate things a little too much. But this remains one of the things most often found around a textarea and, yet, there is no semantical way of passing this useful information which could be used by a potential more appropriate editor or to syntax highlighting. A way of passing such things as parameters may be a good idea. Yeah, there's a lot of requests for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
At 22:36 +0200 UTC, on 2006-06-09, Anne van Kesteren wrote: Quoting Matthew Raymond [EMAIL PROTECTED]: [...] [...] I don't see the utility of enforcing the use of a specific language via a vocabulary list. It's not about enforcing or preventing submission at all. It's about aiding users. As far as I understand that's what the inline spell checking is for. I do see the use for allowing authors to indicate what language submitted content should be in, so that a user-agent can offer spell-/syntax checking if the user wants to. But I don't see at all why you would want to allow authors to flat out state that a spellchecker should be on or off. Just like authors cannot know what font size is best for a user they cannot know whether a spellchecker is useful or a nuisance. (That aside, you can't rely on user-side validation anyway. You need to do that server-side, after the data has been submitted. Thus by allowing authors to state that a spellchecker must be on, you could end up in a stupid 'loop' when the spellchecker guides the user to do one thing, and the server wants another thing.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] input type=text accept=
Anne van Kesteren wrote: [...] I don't see what baring that has on syntax highlighting, though. Highlighting omissions or errors for example... Do you have an example of this? What would such highlighting look like for text editing? I'm not sure I see the use case here. [...] I don't see the utility of enforcing the use of a specific language via a vocabulary list. It's not about enforcing or preventing submission at all. It's about aiding users. As far as I understand that's what the inline spell checking is for. I think this is a misunderstanding as to what you meant by accept input. Let me requote: For spell checking you might want to provide an external dictionary file, because you think the UA might not support the language you accept input in [...] I was interpreting this as meaning that the UA doesn't support the language the server expects the input to be in. Even if you just meant a dictionary of words for the UA to use in case it lacked specific language support, I don't see the point, since the UA will likely support whatever languages the end user can read and write. If, however, we're really just talking about adding words to the UA dictionary temporarily and for a specific site, couldn't we just do that with meta using the same format as we do with keywords? | meta name=vocabulary lang=en-us | content=HTML5, WHATWG, WF2, WA1, WD1, CSS3-UI, TARDIS, ZPM, DHD Are there actually situations where different controls would need different vocabulary?!?
Re: [whatwg] input type=text accept=
L. David Baron wrote: The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. Authors should not have such control. Spell checking is a user agent feature for the *user* and the UA should allow the user to turn it on or off whenever they like. Why should the author have any say about that? Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. If the MIME type is to be used for anything related to spell checking, it should be used in a way that improves the spell checker's logic, not determine whether or not to enable it. For example, given a textarea with either accept=text/plain, no accept attribute (since text/plain should be considered the default for textarea); or any unknown or unsupported MIME type, then the UA can just use its ordinary spell checking algorithm. If, however, it uses accept=text/html or application/xml, etc., the spell checker could be made more intelligent by ignoring elements, attributes and their values (except for some special cases, like alt=... and title=..., where spell checking those values may still be useful). For determining whether or not to provide spell checking for input type=text, browsers should generally do so by default, unless it can be determined that it logically wouldn't be desired by the user. We will soon have type=email, url, etc. which covers quite a few use cases where spell checking wouldn't be desired. For other cases, browsers could use more intelligence to guess what the field is expecting. e.g. Password managers in UAs already guess fairly accurately when a username is being entered and that's another case where spell checking probably wouldn't be desired. For other unknown fields, browsers could use some Artificial Intelligence (AI) to learn what a user typically enables and disables spell checking for. e.g. If a user constantly disables spell checking for fields with input name=address1 or a labelAddress/label associated with the control (or similar variations), the AI could use that to determine that spell checking wouldn't be desired for similar fields. Using this approach, authors have no direct control over user agent behaviour, like spell checking. Instead, it is in their best interest to provide accurate information to enhance the user's experience. So it seems less likely to be abused by authors providing incorrect information in the hope of achieving specific behaviour. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote: Maybe features like spellckeching, syntax highlighting and so on should be controlled via CSS? No, spell checking is a user agent feature that should be controlled by the UA and the user. Authors should have no explicit control over it. Besides, spell checking *is not* presentation, it is UA functionality and so it does not belong in the presentation layer. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
On Sun, 11 Jun 2006 20:11:39 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Maybe features like spellckeching, syntax highlighting and so on should be controlled via CSS? No, spell checking is a user agent feature that should be controlled by the UA and the user. Authors should have no explicit control over it. One can also say that authors should not have explicit control over whether hyperlinks are underlined or not. Besides, spell checking *is not* presentation, it is UA functionality and so it does not belong in the presentation layer. Visual elements = Presentation Interactive elements = Behavior I think these are similar relationships. BTW, isn't the cursor CSS property about behavior? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] input type=text accept=
Quoting Alexey Feldgendler [EMAIL PROTECTED]: One can also say that authors should not have explicit control over whether hyperlinks are underlined or not. The difference is that underlining is presentation, spell checking is not. The functionality of a link cannot be changed with CSS, likewise spell checking shouldn't either. Enabling or disabling spell checking doesn't change the functionality of an input. It can still be used to submit arbitrary text to the server. But misspelled words in an input with spellchecking enabled are underlined with a wavy red line (and the underlining style could even be changed by CSS), and that's presentation. And providing alternate suggestions, synonyms et cetera is too? Having some kind of semantic sheets would be cool I guess for these kind of things... I guess it looks like it would fit in CSS because the functionality is not strictly needed, but I'm unsure if it's really just presentation... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote: On Sun, 11 Jun 2006 21:54:16 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: One can also say that authors should not have explicit control over whether hyperlinks are underlined or not. The difference is that underlining is presentation, spell checking is not. The functionality of a link cannot be changed with CSS, likewise spell checking shouldn't either. Enabling or disabling spell checking doesn't change the functionality of an input. While the core functionality of allowing the user to enter text isn't changed, I'd consider spell checking to be part of the control's functionality, and so disabling it would change the functionality for the user. But misspelled words in an input with spellchecking enabled are underlined with a wavy red line (and the underlining style could even be changed by CSS), and that's presentation. Arguably, yes, but allowing authors to alter the presentation of misspelled words from the UAs default settings would only introduce usability problems. Users may not easily recognise any presentation set by the author as representing a missplled word. UAs may provide a way for the user to set their preferred presentation using some UA-specific means, but there's no need at all for the author to have any control over it. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
On Sun, 11 Jun 2006 23:29:39 +0700, Anne van Kesteren [EMAIL PROTECTED] wrote: One can also say that authors should not have explicit control over whether hyperlinks are underlined or not. The difference is that underlining is presentation, spell checking is not. The functionality of a link cannot be changed with CSS, likewise spell checking shouldn't either. Enabling or disabling spell checking doesn't change the functionality of an input. It can still be used to submit arbitrary text to the server. But misspelled words in an input with spellchecking enabled are underlined with a wavy red line (and the underlining style could even be changed by CSS), and that's presentation. And providing alternate suggestions, synonyms et cetera is too? Having some kind of semantic sheets would be cool I guess for these kind of things... I'd say behavior sheets, not semantic sheets. I guess it looks like it would fit in CSS because the functionality is not strictly needed, but I'm unsure if it's really just presentation... Ok, it's not just presentation. It's about behavior, too. But I don't think that it's wrong to use CSS for behavior. In fact, IE already does so, and I think it's one of IE's strengths. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] input type=text accept=
Anne van Kesteren wrote: Quoting Matthew Raymond [EMAIL PROTECTED]: If, however, we're really just talking about adding words to the UA dictionary temporarily and for a specific site, couldn't we just do that with meta using the same format as we do with keywords? | meta name=vocabulary lang=en-us | content=HTML5, WHATWG, WF2, WA1, WD1, CSS3-UI, TARDIS, ZPM, DHD That seems a bit limited. For larger vocabularies you want those files to be cached, at some point you might want to provide other options as well like synonyms etc., but perhaps I'm making this too complicated. It would be nice to have some advanced vocabulary features, but I suspect that most web authors won't need anything more than what my meta element concept provides, and my approach builds on prior web development knowledge. Are there actually situations where different controls would need different vocabulary?!? Sure, multilingual sites. No, you can handle that by just using multiple meta elements and the |lang| attribute: | meta name=vocabulary lang=en-us content=[US English Words] | meta name=vocabulary lang=en content=[English Words] | meta name=vocabulary lang=fr content=[French Words] This is exactly how the HTML 4.01 spec handles keywords in multiple language, by the way: http://www.w3.org/TR/html4/struct/global.html#edef-META | When several META elements provide language-dependent information | about a document, search engines may filter on the lang attribute to | display search results using the language preferences of the user. Well, we're not dealing with search engines, but you get the idea. Hmm... Automatically add meta keywords to the spell checker's vocabulary? Nah, that wouldn't work, because in most of the cases where you'd need such vocabulary (like forums), such keywords wouldn't make logical sense. Furthermore, adding keywords solely for spell checker vocabulary would distort the results from search engines. Better to have a specific |name| in the meta element for vocabulary than trip up search engines by abusing existing markup.
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote:
On Sun, 11 Jun 2006 23:34:00 +0700, Lachlan Hunt
[EMAIL PROTECTED] wrote:
Enabling or disabling spell checking doesn't change the functionality
of an input.
While the core functionality of allowing the user to enter text isn't
changed, I'd consider spell checking to be part of the control's
functionality, and so disabling it would change the functionality for
the user.
There's nothing really bad in allowing CSS to control behavior to some
extent.
There is if you want to maintain the separation of presentation and
behavior that CSS and Javascript/DOM were designed for.
CSS is a good rule-based language, and there is a use case -- why
not reuse the CSS engine (selectors, cascading etc)?
Because XBL2 already exists, it's more flexible, and it's not really
that hard once you know how to use it:
CSS:
| binding: url('example.xbl#binding1');
XBL2:
| ?xml version=1.0?
| xbl xmlns=http://www.mozilla.org/projects/xbl/xbl2.html;
| binding id=binding1
| handlers
| handler event=click button=0 action=LeftClick();/
| handler event=mouseup button=1 action=MiddleUp();/
| handler event=click button=2 action=RightClick();/
| /handlers
| /binding
| /xbl
Besides, people are already complaining about how the fact that CSS
is non-XML. Adding behavioral markup (beyond binding) will just give
them more of a reason to bitch.
But misspelled words in an input with spellchecking enabled are
underlined with a wavy red line (and the underlining style could even
be changed by CSS), and that's presentation.
Arguably, yes, but allowing authors to alter the presentation of
misspelled words from the UAs default settings would only introduce
usability problems. Users may not easily recognise any presentation set
by the author as representing a missplled word. UAs may provide a way
for the user to set their preferred presentation using some UA-specific
means, but there's no need at all for the author to have any control
over it.
It's not a bigger problem than is the author's ability to style
hyperlinks. Such ability exists for years, but actually on most websites
there are no problems with spotting links. Though authors theoretically
can use CSS to make their sites unusable, almost noone does so.
Unlike hyperlinks, which typically display the URL in the status bar
when you hover over them, spell checking has no discovery short of
right-clicking and hoping it shows the corrected spelling. Furthermore,
you don't have to follow a link, but you usually do have to correct your
spelling when submitting text that may be posted publicly. So which
one's more critical?
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote: On Sun, 11 Jun 2006 23:29:39 +0700, Anne van Kesteren I guess it looks like it would fit in CSS because the functionality is not strictly needed, but I'm unsure if it's really just presentation... Ok, it's not just presentation. It's about behavior, too. But I don't think that it's wrong to use CSS for behavior. In fact, IE already does so, and I think it's one of IE's strengths. IE supports HTML Controls (HTC), and from what I hear, the implementation of this proprietary standard has so many problems it should be considered one of IE's weaknesses, not one of its strengths. By comparison, XBL is so powerful that Dean Edwards used it to implement HTC support in Mozilla. IE supports HTCs via a CSS property called behavior, which is pretty much the same as -moz-binding. (Only you can actually tell that the latter is a vendor extension.) In both cases, we're talking about the use of a single property in CSS, with the rest of the work being done in markup (either XBL or HTC). Note also that XBL can included inside XML compound documents and can bind to elements without CSS properties, which means that XBL can add behavior to markup without CSS. While behavioral styling has its uses, support for behavior in CSS should not exceed what behavior/-moz-binding does. Going further than that doesn't just corrupt CSS, it brings nothing new to the table. In the future, behavior not linked to a specific style sheet will hopefully be done via XHTML+XBL, with a binding property and XBL handling the rest.
Re: [whatwg] input type=text accept=
Quoting L. David Baron [EMAIL PROTECTED]: On Friday 2006-06-09 01:49 +, Ian Hickson wrote: I don't think it's an option because: [...] ...gets out of hand very fast. It may be out of hand (although I don't think it is), but it's much easier for authors and implementors to understand, and much more likely to be interoperably implemented, than what you're proposing. I tend to agree. If you just give some media type it's very unclear what the particular side effects of such a media type would be. Also, it's unclear what text/html would mean for things like syntax highlighting that are mentioned here given that you mostly edit a snippet of it and not a whole document. For spell checking you might want to provide an external dictionary file, because you think the UA might not support the language you accept input in or you're using some really special terms not commonly used. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input type=text accept=
Anne van Kesteren wrote: If you just give some media type it's very unclear what the particular side effects of such a media type would be. No more unclear that the potential side effects of |class|, given the existence of microformats. Also, it's unclear what text/html would mean for things like syntax highlighting that are mentioned here given that you mostly edit a snippet of it and not a whole document. Hmm. We may need a fragment MIME type or something similar, like x-fragment/html. I don't see what baring that has on syntax highlighting, though. The MIME type would, however, be confusing with regards to possibly triggering a WYSIWYG editing feature. My suggestion would be that input type=text and textarea always be for text-based editing regardless of the MIME type, but this shouldn't prevent the use of type-specific macros and syntax highlighting. For spell checking you might want to provide an external dictionary file, because you think the UA might not support the language you accept input in or you're using some really special terms not commonly used. While the idea of supplying additional works for spell checking would be nice (especially in forums that deal with specific topics that tend to have their own vocabulary), I don't see the utility of enforcing the use of a specific language via a vocabulary list. If you really want to enforce the use of a language, I would think the |lang| attribute makes more sense. Using a list of vocabulary words would just be a pointless hack since you can't reasonably expect the UA to prevent submission based on spelling. If submission was suppressed, the first time you'd use a person's name in a text field, the submission would be blocked until you removed it.
Re: [whatwg] input type=text accept=
Michel Fortin wrote: What about input class=spellcheck /? It surely validates with HTML4, and it doesn't get in the way of any other feature. It does not really need to be part of the HTML spec either. This is nothing more than storing boolean attribute values as classes. It's essentially a validation hack. I know that according to the current spec, the class attribute should carry no meaning whatsoever. But I ask the question: is this worse than implying that spell checking should be enabled or disabled based on a particular MIME type? The later could break spell checking when introducing new text types, say text/x-markdown, or text/x- mediawiki, for lightweight formatting syntaxes. MIME types allow for things other than spell checking, like syntax highlighting and UI for tag insertion. For those purposes, a MIME type would actually be quite useful. I'd agree that it's a poor fit for spell checking, but considering there have already been suggestions for specifying the dictionary file to be used for spell checking, I suspect a simple true/false approach to spell check support may be too limited.
Re: [whatwg] input type=text accept=
Quoting Matthew Raymond [EMAIL PROTECTED]: If you just give some media type it's very unclear what the particular side effects of such a media type would be. No more unclear that the potential side effects of |class|, given the existence of microformats. As I understand Ian is what you do with a media type up the the implementation. From what I heard microformats have some formal definition on what is expected when you see a particular class name while a particular URI is inside the profile attribute of the head element. I'm not really sure why you're making this comparison either. [...] I don't see what baring that has on syntax highlighting, though. Highlighting omissions or errors for example... [...] I don't see the utility of enforcing the use of a specific language via a vocabulary list. It's not about enforcing or preventing submission at all. It's about aiding users. As far as I understand that's what the inline spell checking is for. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input type=text accept=
On Wed, 31 May 2006, L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? No, because I don't know what those are, and want to allow for browser vendors to increase their feature set without having to have the spec updated each time. It doesn't seem like this is an area that requires interoperability (who cares if one browser auto-indents and another colours and spell-checks, other than the user of each browser?). And any others people might want? And are there really MIME types that accurately represent the semantics of all the combinations of even just the 4 features you list above that authors will want? If every combination needs a name, what if people want to toggle six different things? This sounds hypothetical. Given that requiring a new flag per feature is not an option (as it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would _you_ propose? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 00:42 +, Ian Hickson wrote: On Wed, 31 May 2006, L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? No, because I don't know what those are, and want to allow for browser vendors to increase their feature set without having to have the spec updated each time. It doesn't seem like this is an area that requires interoperability (who cares if one browser auto-indents and another colours and spell-checks, other than the user of each browser?). The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. It seems more likely to be that the textarea is expected to contain a particular type of text, such as abbreviations or some form of code. The content is unlikely to have an assigned MIME type. I suppose one could be made up, but that would presumably disable everything a UA did on the basis of the contents, which wouldn't necessarily be appropriate. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpffr0IKPp8K.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Thu, 8 Jun 2006, L. David Baron wrote: The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. That, and enable it on input fields. Similarly, there is a desire to indicate that certain textareas should have spell-checking enabled but with an expanded vocabulary that also allows HTML tags (or that disables the spell-checking, if the UA doesn't know how to do that). Looking forwards, there have also been multiple requests to be able to tell the UA that the contents of the field should be syntax-highlighted according to the rules of various languages (typically HTML or XML, and sometimes various programming languages). Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. It seems more likely to be that the textarea is expected to contain a particular type of text, such as abbreviations or some form of code. The content is unlikely to have an assigned MIME type. I suppose one could be made up, but that would presumably disable everything a UA did on the basis of the contents, which wouldn't necessarily be appropriate. There is certainly that possibility; indeed one of the use cases I've heard mentioned is disable spell checking because the text field contains a list of e-mail addresses, which has no MIME type. Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I don't see a better solution. I'm certainly open to better solutions if there are any. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 01:17 +, Ian Hickson wrote: Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I think it is an option, and I don't see why you're so insistent that it isn't. Authors are actually going to want interoperability; to get that, it's required. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpKXHP02UwFo.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Thu, 8 Jun 2006, L. David Baron wrote: On Friday 2006-06-09 01:17 +, Ian Hickson wrote: Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I think it is an option, and I don't see why you're so insistent that it isn't. Authors are actually going to want interoperability; to get that, it's required. I don't think it's an option because: input type=text required maxlength=80 name=subject spellcheck list=subjects value=Hey there inputmode=user startUpper ...or: input type=text required name=formula spellcheck=math inputmode=math highlight=math auto-evaluate ...or: textarea name=source rows=80 spellcheck=off autoindent=C++ highlight=C++ auto-evaluate=off ...gets out of hand very fast. input already has 27 element-specific attributes, plus 5 global attributes, plus 1 deprecated attribute, plus an uncountable number of event handler attributes. Going the road of one-attribute-per-feature would escalate that even faster, especially given that these features don't affect anything other than the way the user interacts with the input field (i.e. they don't affect the actual allowed values, etc). (Also, apparently Mozilla's implementors for this feature have received a request that the feature validate per HTML4's DTD. While I don't consider this a sensible request, and it doesn't affect my opinion of how the feature should be added, it is worth noting that accept= on input elements does current validate per the HTML4 DTD.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
Le 8 juin 2006 à 21:17, Ian Hickson a écrit : I don't see a better solution. I'm certainly open to better solutions if there are any. What about input class=spellcheck /? It surely validates with HTML4, and it doesn't get in the way of any other feature. It does not really need to be part of the HTML spec either. I know that according to the current spec, the class attribute should carry no meaning whatsoever. But I ask the question: is this worse than implying that spell checking should be enabled or disabled based on a particular MIME type? The later could break spell checking when introducing new text types, say text/x-markdown, or text/x- mediawiki, for lightweight formatting syntaxes. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] input type=text accept=
L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? And any others people might want? And are there really MIME types that accurately represent the semantics of all the combinations of even just the 4 features you list above that authors will want? If every combination needs a name, what if people want to toggle six different things? I don't think anyone was planning to specify textarea elements with accept='text/plain' should enable a UA spellcheck feature, if present. At least, I very much hope not. Rather, UAs would be expected to make intelligent decisions about their capabilities for different types of content - in the same way that most offline text editors use different editing features based on the file extension of the content that they are using. This is why, in the Mozilla bug, I am nervous about specifying only text/plain as the MIME type that supports spellchecking since many uses of textarea actually accept a limited subset of text/html, and I don't believe these textareas should have their accept attribute set as text/plain just to ensure that spellchecking works.
Re: [whatwg] input type=text accept=
Lachlan Hunt wrote: L. David Baron wrote: We might want to use the accept attribute in the future to indicate what types of content can be sent, and thus what types of input the user agent should allow. Overloading that to get a boolean for whether spellchecking should be enabled seems broken. AIUI, the accept attribute is just describing what type of input to allow. In this example, when text/plain is specified, the UA has just automatically determined that spell checking would be helpful for the user. Similarly, if text/html, application/javascript or */*+xml were specified, the browser could provide syntax checking. I agree. I don't think the spec should explicitly define type=text/plain as meaning UAs should provide spell checking, it can just provide that as an example of something a UA can do with it. That would be a nice example. Make sure that you mention that spell checker should be enabled only if spell checker supports the language the content is supposed to be written with. If UA only supports spell checking for English and you have input accept=text/plain lang=fi / then the spell checker should be disabled. What should the UA do with accept=text/plain;charset=X, where X is some charset that potentially differs from the page's encoding? e.g. if the page were served as text/html;charset=UTF-8 and contained input type=text accept=text/plain;charset=ISO-8859-1 Then how would that interact with form accept-charset=X? I'd expect the UA to warn the user if he uses characters outside the intersect of ISO-8859-1 and X (that is, the input is expecting characters from ISO-8859-1 character set and the UA is expected to encode those characters with encoding X. I'd assume that ISO-8859-1 in the 'accept' parameter tries to hint that the backend is able to support ISO-8859-1 characters only. In more general sense, if you have HTTP header Content-Type: text/html;charset=H for the page source, accept-charset=F in the form element and accept=text/plain;charset=I in the input field then allowed characters should be those that can be found in all the character sets H, F and I. The idea is that storage backend is only able to support I, user input should be transferred with charset F to the server and the output is later (probably) going to be displayed with charset H, too, so using characters outside those character sets is going to raise problems later on. If I were to decide everybody would be forced to use either UTF-8 or UCS-4... -- Mikko
Re: [whatwg] input type=text accept=
Le 1 juin 2006 à 10:01, Mikko Rantalainen a écrit : That would be a nice example. Make sure that you mention that spell checker should be enabled only if spell checker supports the language the content is supposed to be written with. If UA only supports spell checking for English and you have input accept=text/plain lang=fi / then the spell checker should be disabled. Your idea and example are fine, but it should also be clear that the spell checker should not assume this to be an input for English text only: label lang=en Name: input accept=text/plain /label Very often the interface of a web application isn't available in all languages. but that shouldn't preclude people from writing text in other languages in the form. So if Mikko's idea is mentioned in the spec it should be made clear that the input language expectation isn't inherited from ancestor elements. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] input type=text accept=
The Mozilla guys propose (in bug 339127) to make the accept= attribute on input elements also apply to types other than type=file, with the same meaning as we currently have on textarea. Their particular use case is to use this as a hook for showing or hiding the spell-check UI. What do people think? Good idea? Bad idea? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Wednesday 2006-05-31 19:51 +, Ian Hickson wrote: The Mozilla guys propose (in bug 339127) to make the accept= attribute on input elements also apply to types other than type=file, with the same meaning as we currently have on textarea. Their particular use case is to use this as a hook for showing or hiding the spell-check UI. What do people think? Good idea? Bad idea? This seems like a bad idea to me. We might want to use the accept attribute in the future to indicate what types of content can be sent, and thus what types of input the user agent should allow. Overloading that to get a boolean for whether spellchecking should be enabled seems broken. I'd rather see a new attribute for this. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpW1qXwiBsEF.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
L. David Baron wrote: We might want to use the accept attribute in the future to indicate what types of content can be sent, and thus what types of input the user agent should allow. Overloading that to get a boolean for whether spellchecking should be enabled seems broken. AIUI, the accept attribute is just describing what type of input to allow. In this example, when text/plain is specified, the UA has just automatically determined that spell checking would be helpful for the user. Similarly, if text/html, application/javascript or */*+xml were specified, the browser could provide syntax checking. I don't think the spec should explicitly define type=text/plain as meaning UAs should provide spell checking, it can just provide that as an example of something a UA can do with it. What should the UA do with accept=text/plain;charset=X, where X is some charset that potentially differs from the page's encoding? e.g. if the page were served as text/html;charset=UTF-8 and contained input type=text accept=text/plain;charset=ISO-8859-1 Then how would that interact with form accept-charset=X? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
On Thursday 2006-06-01 00:41 +, Ian Hickson wrote: Well, we want to avoid adding attributes for each feature (spellcheck=on autoindent=on syntaxhighlight=on syntaxcheck=off, as browsers add each feature) -- instead it is better, IMHO at least, to let the UA determine how it should behave based on some semantic information, such as, in this case, the type that is expected to be entered. I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? And any others people might want? And are there really MIME types that accurately represent the semantics of all the combinations of even just the 4 features you list above that authors will want? If every combination needs a name, what if people want to toggle six different things? Generic parameters to MIME types might be a nice solution, but I think we're past that point, unless you want to invent a syntax that represents MIME type - parameter list pairs. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp2AY0tJ6CDb.pgp Description: PGP signature
