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.
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
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
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
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
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
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
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
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,
