What jquery and js developers want from web stds. -- 02 Nov 2011

pi: we're going to talk about the jQuery Standards Group

<npdoty> scribenick: darobin

pi: how we're going to help improve specifications
... things that developers want in the platform that we don't see being actively developed
... how to get better involvement from authors

yk: I don't like the fact that we use "author", most people are really developers
... it's a pet peeve but I won't fight too much on it
... bunch of us were complaining about the standards process at the jq meetup
... why don't we formalise that?
... should sollicit from webdevs what they feel should change
... mostly the higher tier, who have a sense of the failures of the platform
... know how we can make sites 10x faster if we fix document fragments
... people engaged in papering over issues
... process designed for browser vendors
... we wanted to create a forum for that

pi: we want to represent the community
... help them get engaged
... help vendors prioritise properly
... match the pain points from devs
... keen to see jq adopt the new standards

yk: eg RAF, we can really help make half the websites adopt it

pi: feature detection
... current BP in defensive xbrowser dev
... we need robust feature detection
... they can be slow though
... sometimes it can be hard to do, unclear
... e.g. fixed has a different behaviour on mobile
... when it fails people have to resort to UA sniffing

<wycats> https://github.com/jquery/jquery/blob/master/src/support.js

yk shows some of the stuff that jq does

scribe: some of the tests can be quite complex
... we want the spec making process to take feature detect into account
... would make startup a lot faster

pi: false positives are a problem
... FX half-implemented transforms, and broke feat detect
... Chrome has done similar stuff
... then you have the issue of exceptions on common feat detect vectors
... FD has a good reputation
... but when done poorly it's as bad as UA sniffing

yk: historical note, hasFeature failed
... we should learn something about the past ten years

<krisk> can someone place a url to the slide deck in IRC?

<vhardy> robin: what we can do in specs is that have a checklist. There is a limit over what the browsers do.

<vhardy> yk: the spec. could say that an implementation should not claim it implements something unless...

<vhardy> robin: what has an effect is if we design an API in a way that people do not get it wrong.

<vhardy> yk: I think that browsers should not expose a property if they do not implement it.

kris: how many browsers do you think there are?

yk: there are many but only few that people care about
... opera is the bottom line
... there's no one who can address below opera
... a lot of people try to make browsers, few succeed

pi: being able to define what feat detect strategy in the spec would be ideal
... so that it won't false positive

<npdoty> robin: could we collaborate on a best practices document for specification writers? (on things like feature detection in specs)

heycam: webidl could do that
... don't know if we need to do that in the spec
... not sure if editors are more informed

yk: it should be a spec failure to do it wrong

[scribe lost in fast discussion]

yk: I think that browsers are responsive to bugs

js: I think I'm with you
... for functions it's easy, for events it's harder

<npdoty> ... and that browser vendors think that a violation of the spec is a bug

yk: yes, we need something for events

nm: there are certain things where you need total buy-in, but in this case even partial buy-in is already a win
... if it becomes part of the folklore it will become self-sustaining

james: one problem with things like hasFeature is that there's an incentive for vendors to do it wrong

yk: but the disincentive is that you break a lot of sites

js: it is a real problem, we've seen browsers implement new features by just passing feat detect
... since it's new, not breaking the web doesn't apply

yk: the solution to that is using modernizr deep testing

js: so html5test doesn't do that

james: feel bad about using a real example

yk: we're all on the same side
... the competitors to the web platform don't have this problem, can we agree to fix this?

js: I think we had

the problem is partial implementation

ds: in d3ev we tried to go to fine grained feat detect but it wasn't very popular

js: I think that putting this stuff in the spec will take us already far
... I do really like that idea

pi: specs don't capture enough of the rationale
... devs are reverse engineering what a feature affords us
... because they don't read the standards lists

<jrossi2> It's not perfect, but this was somewhat on that idea of sub feature / behavioral detection: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#extended-feature-string

pi: leaving out the UCs means that devs miss great features
... more complex examples help a lot
... written UCs would help
... (shows F:D&S)

<npdoty> http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#use-cases

robin: we should get devs to send us UCs so that we can paste them into the specs

yk: the discussion over the hidden attribute should be summarised in the spec because it makes sense to understand what it's good for

ds: if only so taht people stop asking the same question

pi: we asked on twitter what bugs people wanted fixed
... got 300 devs, some terrible, some really good

yk: (list on screen)

<npdoty> http://paulirish.com/2011/what-feature-would-improve-the-web/

yk: a lot of big features like appcache
... get into the spec and implemented before devs have had a chance to figure out that it's broken
... that feedback should happen earlier and better

kris: you seem like that prime candidates for test writing, we're trying to do more and more tests

js: I'm not actually sure that this solution is fixing the problem

yk: if there's no adoption, if people have events to discuss the issues, it should be considered feedback
... also, there's often a lot of pushback when the feature has already been implemented
... it would be great if there were a W3C forum for developers to say when something is broken
... don't specs need multiple implementations

js: yes, but if the implementation has shipped too long ago, it's hard or impossible to ship

yk: if would be good if devs could play with the feature before it goes to W3C

james: being in a spec isn't fatal
... what's fatal is when people depend on that feature
... we could maybe change appcache because no one is using it

yk: qSA is a great example of something that's broken

js: I agree, we need input from implementers and authors
... maybe we're trying in the wrong way

ds: we need to move on, great discussion we should cover more ground

tobie: the problem boils down to the fact that devs want to use stuff before they go mainstream, but once they use it vendors can't change it
... we need to find a way to fix this

nm: my point is similar, hard to hit sweet spot
... seems like appcache might be okay there
... in Geo that wasn't the case, when the spec went out for comments there were already too many sites using the stuff
... I wasn't wrong tecnically, but they couldn't change

yk: same with qSA

ds: the tail is wagging the dog here, content is easier to change

nm: I think it would be good if the community would push us to a better situation

yk: I think that we should use vendor prefixes properly, make a better contract

js: we need devs involved earlier, how to do it is a harder problem

<Suresh> Would having JQuery submit test cases help?

<scribe> ACTION: Robin to coordinate with pi and yk to get a BP document about feature detection [recorded in http://www.w3.org/2011/11/02-jquery-minutes.html#action01]

yk: try to get a group together around this

kris: write tests

tobie: this can't just be about devs, but also vendors and many others

yk: I would be submitting test for things that we can't do but should

<scribe> ACTION: Robin to look into creating a CG for library developers, browsers, editors to communicate [recorded in http://www.w3.org/2011/11/02-jquery-minutes.html#action02]

pi: we're coordinating with other libraries to move forward
... we have a mailing list
... we have GH issue tracker

<noah> My particular point was: yes, having good implementations ahead of frozen specs is very important, but conversely it is very desirable to publish reasonably good drafts of specifications\ for community comment >before< the code is de facto frozen by too widespread adoption of the early implementations.

(showing examples from the issue tracker)

<wycats> darobin: +1

pi: scaling the group, need to identify champions for specific features

<scribe> ACTION: Robin to look into using GH for spec development [recorded in http://www.w3.org/2011/11/02-jquery-minutes.html#action03]

yk: the ML has evolved into a safer place for devs to make feature proposals

<shepazu> Please support this group… need 4 others http://www.w3.org/community/groups/proposed/#scriptlib

<noah> Dumb question: which ML?

yk: people find it hard to go to public-webapps because they're afraid to look stupid there

pi: we want to show the voice of the devs
... reviewing and submitting test cases

<wycats> https://groups.google.com/forum/#!forum/jquery-standards

pi: I don't think devs realise that tests are written in the language of web devs, when specs aren't

yk: getting specs to link to tests

js: implementing a feature is 50% writing tests — if the tests are already there we get there faster

rn: how do we get the feedback from non-English speakers
... but some features like bidi needs to be from native devs of those languages

ds: having them write tests would already help a lot

james: very much in favour of tests
... they should be in the w3c framework

(global agreement to move in that direction)

<noah> Tnx (oooh...#! URI!)

<krisk> http://www.w3.org/html/wg/wiki/Testing

<krisk> has all the info you need to submit tests to the HTML WG

pi: one of the things that's kind of blocked devs is that lists are overwhelming

js: too many emails, or too high requirements?

all: both

<shepazu> (we need to make it clear that tests are welcome from everyone, and have a review process)

yk: it's easy to bring up ideas but then it devolves into implementation discussions, devs lose track/interest

pi: call for ideas

ds: I have a proposal
... having advocates who can go out there in the community and help drive the ideas they get there

[so more like ambassadors]

scribe: it may seem silly but I see no other way

rn: the vendors already have dev events where they get feedback

<wycats> something like Chrome DevRel for W3C

rn: can't we have that for W3C?

ds: W3C Conf!
... first year we're doing it we're still learning

<npdoty> http://www.w3.org/conf/, discount code "tpac"

ds: next year will be more about feedback
... we can also have smaller things

kris: there's a lot of devs
... millions!
... I'd love to say that I listen to all bugs from devs
... I thikn that participating in the w3c public lists is good because it gets back to it

yk: I thikn that devs of popular libs have super useful information

henri: it could be useful to organise money for great demos, would help everyone

<wycats> https://docs.google.com/present/view?id=ajdqczcmx5pv_148ggbxbfg2&pli=1

<wycats> awwwwwwww

<krisk> http://bit.ly/jqueryw3cpres is the URL :)

<npdoty> Meeting: jQuery Standards breakout session

- DRAFT -

What jquery and js developers want from web stds.

02 Nov 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output