Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

[Jake Verbaten]

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] Review and Browser Vendor Interest in Form Enhancement

[Jake Verbaten]

Personally as a web developer this a feature of forms that I've missed when
I'm building my REST apis and then have to put in some kind of hidden input
for method overwrite.

I know of other developers that also agree that this is a wanted feature.

On Wed, Feb 22, 2012 at 5:38 PM, Adam Barth  wrote:

> Last time I asked around, there didn't seem to be much demand for
> these features so I didn't implement the previous version that was in
> the HTML spec.
>
> Adam
>
>
> On Wed, Feb 22, 2012 at 9:33 AM, Cameron Jones  wrote:
> > Hi,
> >
> > I've submitted a proposal to w3c issue 195 which stems from requests
> > to provide support for additional HTTP methods on forms with specific
> > reference to clients without scripting support. The proposal is based
> > on extending the functionality of forms by exposing the abilities of
> > XHR to declarative markup.
> >
> > I'm keen to highlight the issue to solicit review and feedback on the
> > proposal, and to harvest some degree of the level of interest from
> > browser vendors as to the desirability of implementing the proposal.
> >
> > The proposal itself includes the rationale and details pertaining to
> > the changes. There has been some initial feedback on public-html
> > however i am yet to update the proposal with the recommendations.
> > These amount to:
> >
> > * Implement method attribute values as a blacklist instead of a whitelist
> > * Exclude CONNECT and TRACK methods in addition to TRACE as
> > blacklisted items for synchronicity with XHR specification
> > * Remove "_none" payload attribute state and replace functionality
> > with "disabled" attribute and state
> > * Look at replacing "_async_" form control field as a form submit
> > element attribute for form, button & input retargeting.
> >
> > Proposal:
> > http://www.w3.org/wiki/User:Cjones/ISSUE-195
> >
> > Issue 195:
> > http://www.w3.org/html/wg/tracker/issues/195
> >
> > Thanks,
> > Cameron Jones
>

[whatwg] form.elementName does not return RadioNodeList

[Jake Verbaten]

http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem

says to return a live NodeList

where as

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#dom-htmlformcontrolscollection-nameditem

says to return a RadioNodeList

This is inconsistent. Personally to me, returning a RadioNodeList on the
form namedItem getter makes sense.

Re: [whatwg] WHATWG on Google+

[Jake Verbaten]

>
> With less sarcasm: What use is this if one already reads the blog?


None, this isn't for you. It's for people who use G+. It's a minor addition
that increases the total number of ways you can get information.

As long as G+ is only an optional addition for people who want to use it,
does it really do harm?

The fact I can now type "WHATWG" in G+ search bar and it gives me useful
information is useful.