Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
Sidetracking whether chaining is a useful API design or not isn't useful. Choosing some mechanism to add multiple classes at once is useful, whether that's making add have an arbitary arity, allow it to take an array, allow it to take a space seperated string or allowing add calls to be chained. My personal vote is for arity.
Re: [whatwg] restricted palette for input type=color
Am 03.05.2012 00:50 schrieb Ian Hickson: On Mon, 7 Mar 2011, Markus Ernst wrote: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. You don't really need a colour picker for that... it's more aselect than a colour picker. Or a series of radio buttons. If the presentation is more the concern, then we should probably rely on Web Components to solve the problem (styling aselect with a new presentation, e.g.). It is actually an input field that requires a valid color to be entered; whether it is presented as a color picker or a select box may be up to the UA. I don't see any consistency in having to use different HTML elements whether the selection of colors is defined by the UA (e.g. showing a picker with all colors of the web palette) or by the author. Anyway, 4.10.7.1.15 of the spec states in the bookkeeping details that the @list content and IDL attributes apply to input type=color - if I understand this correctly, it addresses my proposal. [...] - The fact that most CMS do not have restricted color sets so far, does not mean there is no demand for it, but rather shows the difficulty of customizing tools such as TinyMCE. It is a hassle for CMS implementors (who are often not highly skilled JS programmers), if they are expected to respect corporate design guidelines. I don't follow. Right now (before type=color is widely implemented) it's easier to provide a limited set of colours than all colours. Surely then we should see more CMSes have restricted colour sets if it's a matter of difficulty. The CMS I know are shipped with TinyMCE or KHTML or whatever rich text editors. They usually provide a color picker with a predefined set of colors (iirc it is mostly the web palette) by default, which is non-trivial to override or customize; IMHO this is the reason why customized color pickers are not widely used. There are definitely use cases for them.
[whatwg] Allow empty string for input type=color
I apologize in case this has been discussed before - the list archive search seems to be broken right now, as it does not find any matches when searching for color. I just noticed a note in the spec of input type=color http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#color-state-%28type=color%29: Note: In this state, there is always a color picked, and there is no way to set the value to the empty string. If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. I see the following reasons for allowing the empty string: 1. An application might want to give the user the choice of not selecting a color. Not specifying a color is the easiest way to state that the default color should be used, be it black or other. 2. An application might want to force the user to make an explicit selection. It may not be able to distinguish whether black was explicitly selected, or the user forgot to specify a color. 3. Applications need to deal with the empty string anyway, as legacy browsers show a text field.
Re: [whatwg] Allow empty string for input type=color
On Thu, 03 May 2012 02:10:11 -0700, Markus Ernst derer...@gmx.ch wrote: If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. Not selected is not something typically supported by native color pickers. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Allow empty string for input type=color
The way things are done is not always the best way. Most colour pickers are used in instances where not selected would make no sense. However, as you're designing a widget for the web that may be used by billions of people in any number of unforeseen ways, flexibility is a virtue, and the option to clear the field would be an improvement. If you don't allow a not selected or null option, this would basically force all colour widgets to be required fields, which may not be what the form designer wants. To compare, some date pickers do not allow you to clear the field, but some do. For the web, it's a useful feature. Shaun On 2012-05-03 11:46 PM, Anne van Kesteren wrote: On Thu, 03 May 2012 02:10:11 -0700, Markus Ernst derer...@gmx.ch wrote: If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. Not selected is not something typically supported by native color pickers. -- Shaun Moss +61 405478912 facebook.com/mossy2100 twitter.com/mossy2100 skype: mossy2100 groups.drupal.org: mossy2100
Re: [whatwg] Allow empty string for input type=color
On Fri, 2012-05-04 at 04:33 +1000, Shaun Moss wrote: The way things are done is not always the best way. Most colour pickers are used in instances where not selected would make no sense. However, as you're designing a widget for the web that may be used by billions of people in any number of unforeseen ways, flexibility is a virtue, and the option to clear the field would be an improvement. If you don't allow a not selected or null option, this would basically force all colour widgets to be required fields, which may not be what the form designer wants. To compare, some date pickers do not allow you to clear the field, but some do. For the web, it's a useful feature. Shaun On 2012-05-03 11:46 PM, Anne van Kesteren wrote: On Thu, 03 May 2012 02:10:11 -0700, Markus Ernst derer...@gmx.ch wrote: If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. Not selected is not something typically supported by native color pickers. Would the colour pickers allow the selection of the alpha channel at the time of choosing? If so, couldn't you allow a full transparent colour to be used where null couldn't? -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Allow empty string for input type=color
2012/5/3 Ashley Sheridan a...@ashleysheridan.co.uk On Fri, 2012-05-04 at 04:33 +1000, Shaun Moss wrote: The way things are done is not always the best way. Most colour pickers are used in instances where not selected would make no sense. However, as you're designing a widget for the web that may be used by billions of people in any number of unforeseen ways, flexibility is a virtue, and the option to clear the field would be an improvement. If you don't allow a not selected or null option, this would basically force all colour widgets to be required fields, which may not be what the form designer wants. To compare, some date pickers do not allow you to clear the field, but some do. For the web, it's a useful feature. Shaun On 2012-05-03 11:46 PM, Anne van Kesteren wrote: On Thu, 03 May 2012 02:10:11 -0700, Markus Ernst derer...@gmx.ch wrote: If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. Not selected is not something typically supported by native color pickers. Would the colour pickers allow the selection of the alpha channel at the time of choosing? If so, couldn't you allow a full transparent colour to be used where null couldn't? -- Thanks, Ash http://www.ashleysheridan.co.uk Being able to not select a color isn't so strange. Everyone is used to word processors, and they usually have an option to select the color for the text and background. And among those available colors there's an option to use the default text color or to use a transparent background/no color.
Re: [whatwg] multipart/form-data filename encoding: unicode and special characters
On Tue, 01 May 2012 18:12:36 -0700, Evan Jones ev...@csail.mit.edu wrote: … this seems contradictory: Encode using RFC 2388, but do not using the encoding suggested by the RFC. Worse, no browser actually follows the RFC (e.g. they all use UTF-8 encoded parameter values), so that doesn't seem like the right answer. Is there a way out of this mess? Yes. I think we should define multipart/form-data directly in HTML and thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated and not maintained. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] multipart/form-data filename encoding: unicode and special characters
On May 3, 2012, at 17:09 , Anne van Kesteren wrote: Yes. I think we should define multipart/form-data directly in HTML and thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated and not maintained. Right; that would be ideal. Despite the fact that HTML5 references that RFC, browsers don't really follow it. I would be interested in trying to help with this, but again I would certainly need some guidance from people who know more about the vagaries of how the various browsers encode their form parameters / uploaded file names, and why things got that way. It probably would not be helpful for me to try to draft an update to the spec without getting the right implementers on board. Evan -- http://evanjones.ca/
