We should create a file to list any current and previous proposals that had any involvement here.

They might look like this example: https://github.com/tc39/ecma262/blob/master/stage0.md

This way, the current meta issues linking another proposals are unnecessary.

In many cases, querySelectorAll is slower than the counterpart DOM method for simple selectors. For instance, querySelectorAll(‘tagName’) is slower than getElementsByTagName(‘tagName’).

Specific Issues

• querySelectorAll is slower than the lower-level DOM methods
  • querySelectorAll(tag) is slower than getElementsByTagName
  • querySelectorAll(class) is slower than getElementsByClassName
  • querySelectorAll(id) is slower than getElementById
• Action Items:
  • Do benchmarking on all browsers
  • File individual tickets with browser vendors for each instance in which querySelectorAll is slower than the lower-level DOM method
  • Make sure that the same mistake is not repeated with queryScopedSelector
    • Note: Why can we not just fix querySelectorAll? Are there cases where web authors are relying on the non-scoped behavior?
• External Contact: Browser vendors

References

http://www.w3.org/TR/selectors-api/
http://www.w3.org/TR/selectors-api2/

Conversation

http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html

We need to list the current representatives of the jQuery Foundation on standards bodies and working groups. My plan is to create another .md document on this repo.

While we have many participants involved with standards, we also have people fully representing the jQuery Foundation, using @kborchers' words: "checking in before meetings to discuss agenda items being presented or items the foundation may want to ask be added to an agenda, being at the meetings (in person as budget allows) and participating, and reporting back after meetings on decisions being made or follow-ups that may need further input from the foundation as a whole to best represent everyone’s best interest."

For now I can list the following:

TC39

• Rick Waldron - @rwaldron
• Leo Balter - @leobalter

Web Platform WG

• Alexander Schmitz - @arschmitz

Dave Methvin (@dmethvin) may also be listed as the current coordinator of the standards team.

The document can also explain the expected work from the representatives, the following are some ideas adapted from this repo's wiki page:

The jQuery Foundation invests significant resources in its efforts to drive Web standards on behalf of developers. The Standards Representatives coordinates those efforts, communicating on a regular basis with both the community and the projects hosted within the jQuery Foundation.

The Standards Representatives will:

• Know what Foundation projects are doing related to standards, and what departments or projects are involved to properly disseminate information and solicit feedback.
• Act as ambassadors to the wider web development community, and provide feedback to the Foundation regarding its impact in that community.
• State their affiliation with the jQuery Foundation, particularly in conferences or meetings where their attendance is a result of affiliation with, or funded by, the Foundation.
• Provide a high-level summary of the meetings they attend, and distribute those reports as widely as possible. If there is no confidential information, public distribution is preferred.
• Distribute information about upcoming standards meetings within the jQuery Foundation to ensure that they are attended by the appropriate representatives.
• Inform the jQuery Foundation and interested projects of upcoming votes in the standards bodies, and take feedback on the appropriate way to vote on the matter.
• Regularly provide reasonable data for expenses reimbursement regarding any available budget to attend meetings or events associated to their respective representation work.

The spec for pointer lock has been substantially updated since it was originally published in 2013. The Web Platform group is considering republishing the current spec as a CR.

Current Spec: https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
Published Spec: https://www.w3.org/TR/2013/CR-pointerlock-20131217/

If anyone has any feedback or concerns on the current spec I would love to hear them so I can pass them on.

https://github.com/leobalter/proposal-setmap-offrom

After catching a conversation on twitter I volunteered to work on this proposal, which adds the of and from methods to Set, Map, WeakSet and WeakMap constructors.

It got my personal interest as I wrote tests (on test262) for Array.of, Array.from, the same respective tests for TypedArrays and tests for Map, WeakSet and WeakMap. This was some nice opportunity to continue API work with some very useful features.

An issue came up in CSSWG about style scoping. It was linked to a kind of confused seeming thread but numerous people in CSSWG confirmed that they are consistently asked questions about this and don't really know what to say.

Here's the relevant IRC log with what I had to say: TL;DR: It's complicated, there's history and experimentation, CSSWG alone probably can't solve this problem, we need to involve developers by exposing the right things (several already underway or available), describing the history and problem and that solutions should be incubated.

Tab is going to work on putting together a history and maybe a post, probably some work in WICG.

If there are thoughts or disagreements, let me know.

astearns: And TabAtkins is still collecting data there.

12:19 PM A
w3c/csswg-drafts#270

12:19 PM D
Topic: [css-scoping] Support for CSS namespaces
12:20 PM ChrisL: This si the what to do with shadowDom thing. How do you style, do selectors work, etc. I think closing and saying we won't fix is doing the community a disservice. I'm hearing a lot of pain where people want to be able to do modularizable solutions. I see huge long naming conventions.

12:20 PM B<bkardell_> Brian Kardell
that issue seems confused

12:20 PM D
ChrisL: It's not do we have namespaces, it's what are we working toward to have local variable type styling for theme-ability. Just saying we won't do anything for a few years isn't appropriate.
12:21 PM TabAtkins: Today the answer is web components. THere are some holes and we'd like it something like easier to do declaritively, but we'd like it to mature to see where we need to go in. That's our focus. Everything that people suggest won't do what they want. You want hte full both directions that web components allow. Their solutions dont' think both directions. And browsers aren't doing scoped styles.
12:21 PM ChrisL: What does web componets allow? Can you theme and style? I'm not familiar enough

12:22 PM B<bkardell_> Brian Kardell
TabAtkins: it could be declarative today, right? all you need is a web component that just does that.

12:22 PM D
TabAtkins: If you put things in a shadow tree they're stylable in the tree. THe styles inside can't go out and the styles outside can't go in. So it's a full self-contained piece of HTML that won't be messed up by styling o nthe rest of the page.
12:22 PM leaverou: How are they themed?
12:22 PM leaverou: I've refraned from using components because they're not skin-able.

12:23 PM B<bkardell_> Brian Kardell
q+
12:23 PM Z— Zakim sees ChrisL, bkardell_ on the speaker queue

12:23 PM D
TabAtkins: We have some soultion now. If you use variables you can pass in styling one piece at a time. Not the most convient. We have the @apply rule that was generally accepted that lets you shift entire style blocks across the boundary.

12:23 PM C
q-
12:23 PM Z— Zakim sees bkardell_ on the speaker queue

12:24 PM D
TabAtkins: From inside the tree you can detect what's going on from the outside like if a class is on an ancestor so you can adjust accordingly. SO you can ship with multiple themes that do something depending on a class outside.

12:24 PM A
ack bkardell_
12:24 PM Z— Zakim sees no one on the speaker queue

12:24 PM I<iank_>
Polymer has a writeup here of the mixin/custom-prop solution: https://www.polymer-project.org/1.0/docs/devguide/styling#custom-css-properties

12:25 PM D
bkardell_: I wanted to add that one of the good things about this is that we did experiment with several things. Chrome and polymer had experiments to allow you to explicitly cross boundaries. We had a number of discussions based on what people thought they wanted, but when we gave it it wasn't really what they wanted.
12:25 PM bkardell_: Going forward we shoudl expose basic things, allow experimentation and progress. This is new ground. The only way we can know this is the right thing is to be allowed to use it.
12:26 PM TabAtkins: He's referring to the ::deep selector. It led to unending problems of people changing thigns they didn't mean to. So we diled back to explicit sharing. It's all the flexability without a footgun
12:27 PM leaverou: This sounds good but I'm skeptical that a component exposes its variable so to change it you have to change your CSS. Assuming there's no native slide, you want to use a slider and than another slider you have to look up the doc. Native components to accept some styling. It would be nice if author components did the same thing.
12:27 PM TabAtkins: That's good feedback. WE should keep that in mind as we move toward more declaritive.

12:27 PM B<bkardell_> Brian Kardell
but if we expose the right bits, then maybe people like leaverou can experiment with ways to do that in wicg :)

12:27 PM F
ChrisL w3c/csswg-drafts#270 (comment) ?

12:27 PM D
leaverou: I'm not sure this is jsut shadowDOM. I think it may also be nesting. That's another thing authors ask me about.
12:28 PM leaverou: Authors ask me a lot about nesting and scoping in every conference for the last few months. I don't know what to tell them.
12:28 PM leaverou: So nesting is another big thing. This is what the naming conventions are tryign to address.

12:28 PM F
www-style thread!!! :D

12:28 PM B<bkardell_> Brian Kardell
fantasai: nooooooooooooooo
12:28 PM :)
12:29 PM F— fantasai misses subthreading :(

12:29 PM D
astearns: So there's several issues. Scolping, nesting, a moredeclaritive approach to components. I'm not sure a single github thread will be that helpful. It might be good to have a single place with the history of this conversation. So look we have this deep selector and it didn't work like we wanted.
12:29 PM astearns: I'm thinking a wiki page with all the history where we can take this github and point it there to say we've worked on these things, we're trying these things. So we're not shutting down convo but it's not a sincle thread.

12:29 PM B<bkardell_> Brian Kardell
this really does sound to me like a great thing to bring up in wicg before csswg itself burns time on it... that is inclusive of devs and hopefully then we can bring back the good ideas

12:30 PM
astearns: I want a place where we can engage the community on these issues and some place with the history of what we tried and what we're looking to do.
12:30 PM ChrisL: SOunds great. So who sound write it and who has the material to begin it.
12:30 PM TabAtkins: I can start writing that. I have the history in my head.

12:30 PM B<bkardell_> Brian Kardell
q+
12:30 PM Z— Zakim sees bkardell_ on the speaker queue

12:30 PM D
fantasai: A blog post would be nice, but the commenting on our blog is too broken.

12:30 PM B<bkardell_> Brian Kardell
q-
12:30 PM Z— Zakim sees no one on the speaker queue

12:31 PM D
astearns: And bkardell_ mentioned on IRC that this may be good for the incubation group.

12:31 PM B<bkardell_> Brian Kardell
also repos and wikis and all available on wicg

Both iOS and Android make the generic click event seem unresponsive compared to their desktop counterparts. Whatever the motivation for that was, it makes building responsive web mobile apps a lot harder.

While jQuery Mobile offers a solution for this issue (https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.vmouse.js), its a pretty complex implementation and very hard to apply outside the context of jQuery Mobile itself.

Obviously an incomplete description, but I hope to at least start a discussion around this.

Chapters.IO, that is. Don't have rights to tag / label. Thanks!

Problem

The current spec says:

If the registerProtocolHandler() method is invoked with a scheme that is neither a whitelisted scheme nor a scheme whose value starts with the substring "web+" and otherwise contains only characters in the range U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, the user agent must throw a SecurityError exception.

The following schemes are the whitelisted schemes:

• irc
• mailto
• mms
• news
• nntp
• sms
• smsto
• tel
• urn
• webcal

This list can be changed. If there are schemes that should be added, please send feedback.

Whitelisted, huh?

This is terrifying.

In Wikipedia there is a list of — how many? — over a hundred official and unofficial schemes.

And that's precisely because none of them had to be standartized before use.

Example

Now imagine that you have an idea of some Web application with a brand new URL scheme — such as pay-to-github:username?amount (compare it with the existing skype:username?sendfile).

Unfortunately, you cannot start seriously coding your application (as a Web application) for the next ten years, because your scheme has to make its way to the WhatWG whitelist and only then (according to the spec) to the separate whitelists inside of several browser versions. (IE6 is ten years old and still in use. Guess when some IE11, which does not support your scheme currently, will grow old enough to die?…)

Well, you may implement your URI scheme instantly — but only in standalone applications for the required platforms. Not for the wide cross-platform Web. At least not for the next ten years.

Solution

A blacklist of dangerous schemes (schemes to be never redefined by Web applications) should be enough to ensure security. Otherwise the innovation would suffer.

UserScripts are installable JavaScript. They are a cross-browser method of JavaScript injection.

UserScript support is widespread, but inconsistent - some browsers provide native support, while others require an extension. Different UserScript engines support different metadata keys, different security restrictions (eg cross-domain XHR), different global functions (GM_*).

http://en.wikipedia.org/wiki/Greasemonkey

From the public-html mailing list.

This is a call for consensus to request that W3C publish the current HTML
Working Draft (WD) as a Candidate Recommendation (CR). It has been posted to
[email protected] as the official email for this WG.

Please reply to this thread on [email protected] no later than end of
day on 10 June. Positive responses are preferred and encouraged, silence
will be considered as assent.

The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
make it more reliable, more readable and understandable, and a better match
for reality. Substantial changes between HTML5 and HTML5.1 can be found in
the spec [2].

When a specification moves to CR it triggers a Call For Exclusions, per
section 4 of the W3C Patent Policy [3]. No substantive additions can be made
to a specification in CR without starting a new Call for Exclusions, so we
will put HTML5.1 into "feature freeze". It is possible to make editorial
updates as necessary, and features marked "At Risk" may be removed if found
not to be interoperable.

The following features are considered "at risk". If we cannot identify at
least two shipping implementations, they will be marked "at risk" in the CR
and may be removed from the Proposed Recommendation.

keygen element. [issue 43]
label as a reassociatable element [issue 109]
Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
159/375/422]
registerContentHandler [Issue 233]
inputmode attribute of the input element [issue 269]
autofill of form elements [issue 372]
menu, menuitem and context menus. [issue 373]
dialog element [issue 427]
Text tracks exposing in-band metadata best practices [Issue 461]
datetime and datatime-local states of the input element [Issue 462]

Please share implementation details for any of these features on Github. To
mark other features "at risk", please identify them by 10th June (ideally by
filing an issue and providing a test case).

At the same time we move HTML5.1 into CR, we plan to continue updating the
Editor's Draft, and in the next few weeks we expect to post a Call for
Consensus to publish it as the First Public Working Draft of HTML5.2, so
improving HTML will continue without a pause. It also means that changes
that didn't make it into
HTML5.1 will not have long to wait before being incorporated into the
specification.

Léonie on behalf of the WP chairs and team, and HTML editors.
[1] https://www.w3.org/TR/html51/
[2] https://www.w3.org/TR/html51/changes.html#changes
[3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion

[issue 43] w3c/html#43
[issue 109] w3c/html#109
[issues 159/375/422] w3c/html#159 and links [issue
233] w3c/html#233
[issue 269] w3c/html#269
[issue 372] w3c/html#372
[issue 373] w3c/html#373
[issue 427] w3c/html#427
[Issue 461] w3c/html#461
[Issue 462] w3c/html#462

As the maintainer of an animation / effects library, this issue has been a thorn in my side multiple times. Trying to determine if an element is positioned using left, top or right, bottom or some combination of all of them is currently impossible to do in a cross browser way. The "Computed Style" of right and bottom in webkit will return auto but FF spoils the day by returning an actual px value (which by my interpretation is actually the correct value to return).

After animating elements, my code must either assume that the element was positioned left and top since there is no way to determine what the initial positioning actually was, or accept some sort of configuration parameter to tell it which to use. This means that after running my effect code on your arbitrary div that was positioned using right and bottom it will no longer be positioned relative to the bottom right as its relative container resizes.

The issue of knowing if a CSS property is auto probably has more uses than just left and top. I could see width and height also being useful to know if it is auto or specifically set.

Specific Issues

• Makes it impossible to detect if an element is positioned with right and bottom

Specific Suggestions

• isCSSAuto( property ) - Some method (be it on the computed style object, or somewhere else) could be provided to determine if a style property is auto before computation.
• right and bottom shouldn't return auto on a computed style object.

There's a new report file on this repo with the highlights from the meeting that happened last month in Munich.

https://github.com/jquery-foundation/standards/blob/master/reports/TC39/2016-05.md

This report is opinionated - from my pov - and does not replace the meeting notes.

Please use this issue for comments.

Thanks @kborchers and @tkellen for reviewing it.

Hi,

Any way or project for a blacklist.
I have a friend I don't want to receive anymore of her so many sms.

I have read a similar subject 6 month ago but with no progress on this issue since

Thank you.

PM from France

This is already technically started, but let's make sure there's a place to track them all for now until we get to a better place. These are coordinated with pittsburgh's code and supply and bearded and for standards folks we have myself, @hmig, @wilkie and likely a few others.

I don't seem to have rights to create a label or template for this, so adopting [mailing-list] tag until then and winging it.

@jyasskin from google has offered to/expressed interest in helping mentor in/attend/give standards feedback for chapters if someone can hook him up with someone organizing such a meetup there.

I don't run a meetup, but I know some of the people who run Seattle JS, and I was talking to @nolanlawson about Chapters.io and the problems it's trying to tackle last night. If there are other people who are interested in the area, I'd be happy to help organize.

Problem: Imagemap AREA tags' offsetLeft and offsetTop are not defined in the HTML spec which has led to different browsers exhibiting different behaviors.

Consider an HTML ImageMap with a couple of AREA’s:

    <img alt="Image" src="./TestImage.jpg" usemap="#myMap" />
    <map name="myMap" id="myMap">
        <area id="Fox" alt="Fox" shape="rect" coords="344,0,530,170" />
        <area id="Grass" alt="Grass" shape="rect" coords="80,160,250,280" />
    </map>

Using jQuery/javascript, attach mouseover events to the AREA tags. In the event handler, examine the AREA tag’s offset left & top parameters.

IE exhibits what I believe to be the correct behavior, but both Firefox and Chrome exhibit incorrect, and different behaviors:

• IE9 reports the offsetLeft and offsetTop correctly
• Firefox returns the offsetLeft and offsetTop of the image itself.
• WebKit/Chrome return 0 for both offsetLeft and offsetTop!

This bug prevents reliably determination of the bounding box surrounding an AREA using the offsetLeft and offsetTop parameters. Because of the inconsistent browser behaviors, To work around this, developers have to write code to calculate the bounding box from the cords list for rect and poly area types and also for circle area types.

I’ve filed bugs against Firefox (here) and Chrome (here) for this issue.

I had originally discovered this issue when using the jQuery .position() method which fails because of the above difference in behavior. Please consider driving a common understanding of the offsetTop and offsetLeft properties of AREA tags through the W3C HTML spec process.

It needs to be updated with the current expected usage of this repo.

@triblondon runs meetups/is involved in communities in London and Japan (sorry I don't know where in Japan) and is willing to help us here if we can connect some additional standards folks to start chapters efforts there.

As web authors aren’t watching standards lists, much of the useful practical info about how these standards improve developer ergonomics is lost. Specs boil down the discussions for implementers and APIs but author-facing info isn’t prioritized. A good example: nearly all developers consider it a “trick” that you rev a comment in an appcache manifest in order to indicate the cache needs to be refreshed.

Specific issues

• As these details are not published in the specs, they don’t make it into developer documentation and thus, it takes months and years of experimentation to “discover” features and use cases of common features.
• In many cases, new specifications do not clearly outline use-cases that led to the specific implementations. Often, this information is clearly outlined in long mailing list threads, but those discussions are not synopsized in the specification.
• Specification authors and implementers don’t always think about feature detection, which lead to false positives and false negatives. This hurts a recognized best practice and encourages more UA sniffing.

Specific Suggestions

• Specification authors and editors should document intended use-cases and patterns for all newly developed features.
• When discussions on public mailing lists inform a specification, the editor of the specification should synopsize the results of the discussion in the specification.
• All new feature specifications should include a mechanism, in the specification, for detecting whether the feature is present in a particular user agent.
• The mechanism for filing “bugs” against a specification should be clearly indicated in the official location for the specification, especially during the drafting process.

Notes

The HTML5 specification’s “web author” mode is a very good starting point for improving the web author view of a specification. (http://developers.whatwg.org)

The new HTML input types are great, but they really suck when writing UI widgets. CSS3 System Appearance is important, but seemingly ignored by browser vendors.

Here are snippets from a long email thread related to this:

Scott González:
As you're probably all aware, in jQuery Mobile we degrade the new HTML input types to avoid getting the new UIs. I was going to email the WHATWG asking for a way to keep all the semantics and validation that comes with the new input types, but opt-out of the improved UIs. Then I found out about CSS3 System Appearance. Unfortunately, this doesn't seem to be well supported. Are you guys able to provide any insight into how the browser vendors feel about this spec (importance, priority, missing features, etc.)?

I don't like using the new input types because they're much harder to enhance and I know I'm not alone here. Having good support for falling back to text fields could go a long way.

Thanks.

Scott Jehl:
Just to add to this… we've set it up to degrade certain types to types other than "text" in some cases. For example, @type=range falls back to "number" once we append our slider, which allows us to keep the numeric keyboard and min/max attributes. Still, it means we have to deal with buggy @type=number implementations alongside our slider now… :/

Mike Taylor:
I can't speak for Opera beyond what I know--but Bruce Lawson is trying internally to get someone to work with Tentek Celik (now at Mozilla) as a co-editor of the CSS3 UI module, possibly Lachlan Hardy. As for how long it will take us to implement support for -o-appearance {} or just appearance {}, I have no idea, but I believe we'll get there.

Rey Bango:
From what I’ve read, most browser vendors are supporting what they believe are a consistent experience for these new controls and don’t recommend modifying the UI/UX because they want users to have a consistent experience regardless of which browser they use. So if a user launches Chrome, the experience they get from a datepicker should be similar to what they’d get in FF, Opera, IE or Safari.

Scott González:
The problem is that no matter how consistent the UI/UX is, I want to opt-out because it will never be good enough. I want to customize the UI to look like my app, layer on additional functionality, etc. All of this is possible today without the new input types. However, once the new input types are used, this becomes more difficult. For example, enhancing a text field into a datepicker is really common, but you can't do this with a date field because of the new UI. I really don't think that JS implementations of these input types are ever going to die, no matter how good the native implementations work. There's just too much functionality that users will want that won't be possible because the APIs would be too large to spec. Falling all the way back to text fields works, but then we lose all the other benefits, such as the new attributes/methods, built-in validation, type-specific virtual keyboards, etc.

So the end goal is still to have consistent UI/UX cross-browser, but not necessarily cross-site.

Paul Irish:
I've seen a lot of people use the prefixed -webkit-appearance to great effect.
http://trentwalton.com/2010/07/14/css-webkit-appearance/

But I have no seen a prefixed moz or o in action, so I imagine we're waiting there.
Still, this should get you pretty far on target devices.

Mike Taylor:
Scott, I think you should email the WHATWG, as you make great points. I'd love to point to your email internally and say, look--people want this, etc.

Rey Bango:
Yep agreed. I’d like to do the same.

Paul Irish:
Do eeet.

Scott González:
Sure, I can email WHATWG but I'm pretty sure the immediate response
will be either 1) this is a CSS issue and therefore doesn't belong in
this list or 2) this is already spec'd, lobby the browser vendors.

I know I can make a solid argument for having this feature, but
knowing that the functionality is already spec'd I'm not sure how to
proceed through WHATWG.

The html group is looking for feedback on some issues related to image maps mainly

1. Do you meet them anywhere on the web today?
2. Do you know of cases where one image map is applied to two images - e.g. one at the top and another at the bottom of a page?
3. If the answer to 2 is yes, do you care whether you go through them twice, i.e. each time you meet the image, or once, where the actual map is in the HTML source? This probably only applies to those who navigate with the keyboard.

See also HTML issue w3c/html#297

I'm opening this issue to revamp an issue I already raised in the W3C position mailing list that I feel received very little attention.

The point I'm making is the following:

The specifications of position: sticky don't mention any event fired when an element is stuck and when it returns to its original position, for example something like stickystart and stickyend. I think this could be very useful and it has different use cases.

The first use case is a website that needs to decrease the margin of a navigation bar when it starts sticking. Another use case might be to have an element that takes the full width of the page when it's sticking but a different width when it's in its original position.

A use case I can think of is an element that should have the width of its parent when is not sticking and the width of the window when sticking. An example is shown in this demo I've created:

https://jsfiddle.net/638rjsty/

And this is the result I'd like to achieve:

https://jsfiddle.net/4otjrrpf/

The second demo uses a library to simulate the support for position: sticky, so it can be seen in any modern browser.

I'm not sure there is a terribly lot to do with this one, but adding it here for completeness and so we can keep track of which/where - Bocoup coordinates meetups in Boston and has a space and we've been talking for a while - @Wilto is going to get this one rolling.

Prologue

We've all been there, all you want to do is check for a specific key event, like the character "?". So you go through the normal routines of Googling for the keycode, because you cannot just use "?", so you find out the keycode (or is it charcode?) is 191. You put in the JavaScript to check for the "?" keypress...

$('body').keyup(function (e) {
    if((e.keyCode || e.charCode) === 191) { // 191 is ?, because, y'know, that makes sense
       doStuff();
    }
});

Then you get French users complaining that their Azerty keyboards don't work when you use this because they have a different keyboard layout (shift+, gets them question mark, for US/UK Qwerty keyboards its shift+/). Then you get complaints from Opera users, because in Opera, ? actually has a keyCode of 47. So now you're code looks like:

$('body').keyup(function (e) {
    if((e.keyCode || e.charCode) === 191 || (e.keyCode || e.charCode) === 47) {
       doStuff();
    }
});

Why isn't there a simple answer for this?!

DOM Level 3 Specification

So it turns out W3C DOM Level 3 events specification actually has some details to simplify this. It describes a KeyboardEvent.key attribute which will be populated with printable characters, if they are printable (e.g 1, A, or ?), otherwise, it has a standard set of names for all other keyboard characters (see here: http://www.w3.org/TR/DOM-Level-3-Events/#key-values-list). There is also a KeyboardEvent.char attribute which will give a unicode representation of the key. Secondary to this there is also a KeyboardEvent.location which can tell you where in the keyboard the button was pressed, which can determine between the left/right ctrl keys, or if the device is a mobile phone, etc.

Proposal

We should push all browsers to adopt the DOM Lvl3 specs for KeyboardEvent.key, KeyboardEvent.char and KeyboardEvent.location.

Bug Links

• Firefox/Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=680830
• Webkit/Chrome/Safari: ???
• Opera: ???

There are issues at the spec level and the browser level that make classList untenable for authoring in javascript and authors of libraries.

Specific issues

• The API makes it too arduous to work with as a replacement for className manipulation. The authoring experience is very awkward.
• Performance of the method calls isn't good enough for libraries to consider adoption.

Specific Suggestions

• Return value of classList methods should be a DOMTokenList instead of undefined. This allows chaining.

elem.classList.remove('oldnbusted').add('newhostness'); 

• Methods need to take multiple class arguments:

elem.classList.remove('classone classtwo')

• Performance in implementations need to improve. An effort was made in jQuery to add classList support but performance was inferior to className manip: http://jsperf.com/classlist-vs-addclass/2

• On perf, Resig concluded:

  So it seems like this doesn't provide any perf benefit over our current solution (which is unfortunate) - thus we'll probably want to hold off on landing this until we can get some appreciable gains.

• On perf, I asked a WebKit engineer and he said:

One of the problem with almost all the js solutions I've seen is that they are not complete. In other words they fail with some input data. If it turns out that a js solution that is complete is faster than the webkit one we should probably look at this again.

For completeness see Webkit's classList layoutTests

Notes

Spec on classList: http://www.w3.org/TR/html5/common-dom-interfaces.html#domtokenlist-0

+@miketaylr

The meeting is happening next week and you can check the agenda here.

My plans for the meetings consist on:

• present a new proposal for Object.enumerable{Keys,Values,Entries}, hopefully moving it from stage 0 to 1
• Support a PR to tc39/ecma262 from Claude Pache: Disregard lastIndex for non-global non-sticky regexps
• Informally discuss about our current pre-proposals (see #23, #33 and #40) with other TC39 Representatives

I'm also very interested on some other topics already in the agenda:

• Shared memory and atomics: This extends the use of TypedArrays in a very optimized way, and much more. This is probably the most complex theme for the next meeting but it's being worked very well. I hope it makes to stage 3.
• System.global
• Promise.prototype.finally which might conflict with cancelable promises but it is simple a gets the job done. See: #46 (comment)

If you have any feedback, question or suggestion from any topic, we can use this issue to discuss.

I'll publish a report after the meeting.

I'd like to discuss and eventually propose the introduction of an Array.prototype.shuffle method. I think this is a method used in several context and helpful in many cases including but not limited to games.

Before creating a repository with a more formal proposition, I'd like to discuss the idea with the group and gather some feedback.

Problem

Imagine that registerProtocolHandler() is successfully called, and some given site is registered as a handler for some non-standard URL scheme.

What happens then?

We have isProtocolHandlerRegistered() on the client side to check that registration.

On the other hand, unfortunately, there is no way for a server-side application to determine whether a specific URL scheme is available on the client.

That's why, in server-generated content, any non-standard URL schemes inevitably become prefixed nevertheless. Prefixed to guarantee their safety. (That is, to guarantee that they would actually work.) Prefixed by the name of some handler site, known by the server script's author — but not necessarily the same handler that was registered by registerProtocolHandler() on the client side.

Example

For example, let's imagine that we have non-standard area:// URL scheme registered.

Any server script has to refrain from making <a href="``area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707``"> because, as you may have already guessed, the server does not know (cannot know) whether simple area://… URLs are safe there; it does not know whether any handler have been registered for such URLs.

The server script has to use significantly longer (and prefixed) form, such as <a href="http://fghi.pp.ru/?``area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707"> (where http://fghi.pp.ru/ is the URL handler server that has to appear as a prefix). It is longer, but it is safe.

Of course, it seems to effectively defeat the purpose of isProtocolHandlerRegistered().

A side note: the example is partially real

The draft area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707 actually defines area:// URLs, and fghi.pp.ru is currently one of their handler sites (the hostname may change in the future).

However, that site does not call isProtocolHandlerRegistered() because the function is not currently implemented in any browser.

Workaround

The site may, of course, call isProtocolHandlerRegistered() function on each page, and set a cookie to indicate whether that function returns registered.

However, there are the following problems:

1. The cookie is, naturally, non-existent before the first visit. The URLs should appear prefixed (which is not efficient), or the page should instantly reload itself on the first visit (which is, most likely, even more inefficient).
2. If isProtocolHandlerRegistered() does not return registered but the cookie says the handler was previously registered, then the cookie has to be reset and the page has to be reloaded instantly (which is also not efficient).
3. The user can disable cookies. (Which can in turn be worked around; for example, with PHP session ID as a GET parameter; but still — — —)
4. Even if isProtocolHandlerRegistered() does return registered, the value is not reliable. The current spec says that value means «the given handler has been registered or the site is blocked from registering the handler». If the site is blocked, then we still have zero information about whether handler://... URLs are safe.

(A side note: the last problem is a serious client-side problem as well.)

Proposed solution

Make a new HTTP request header and name it Accept-URL-Schemes (similar to Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges).

Let that header contain the complete and reliable list of URLs the user-agent is willing to expect in <a href="…"> and in similar attributes and properties (willing to expect, willing to accept, and is ready to activate them on click or otherwise) in the Web content.

Example:

Accept-URL-Schemes: http, https, mailto, tel, sms, mms, news, nntp, irc, ircs, skype, ed2k, bitcoin, facetime, magnet, steam, view-source, some-other-non-standard-scheme

Security and privacy concerns

• The browser should prevent continous registration spamming. Even if the site continuously runs registerProtocolHandler() until Accept-URL-Schemes contains some scheme, the user MUST be given an option to break that loop. However, intentionally adding wrong values to Accept-URL-Schemes list should not be used as the method of breaking that loop; the user will probably not be happy if finally silently gets a list of links that cannot be activated.
• A site should be prevented from being able to bargain for protocol registering. For example, the scenario «in order to login for porn, register your mailto handler here and allow us to harvest your addressees for spam» should not be made possible. A mere checkbox («I register evil.example.org as a handler for mailto links that appear on the pages of evil.example.org only.») should be enough for the site to see mailto in Accept-URL-Schemes (and even to verify that with some mailto:[email protected] link, which, when clicked on the evil site, will actually lead to the same site's handler page), but no other harm would occur.

The Array#sample proposal will be introduced to TC39 potentially in the next meeting.

I might champion it, and the work there is currently made by @tkellen and @ashleygwilliams.

Every feedback there is important, thanks!

Because the cache manifest requires that the main HTML asset is cached, it is difficult for people with existing pages to adopt it. If they wanted to use the cache manifest, they would have to change their site to make the main index.html more permanent, and use JavaScript to update the content on the main page and prompt the user to refresh.

Specific Issues

• Use of the cache manifest mandates a user-implemented refresh-to-update UI.
• It is not possible to use the cache manifest for offline support without also opting in to its aggressive non-blocking behavior when the user agent is online.
• If any resources in the CACHE section return a 404, the entire cache manifest is disabled

Specific Suggestions

• It should be possible to declare that the main HTML resource should only be non-blockingly served from the cache if the user agent is offline. If the user agent is online, a single blocking request would first verify the freshness of the cache using the existing semantics.
  • Action Item: What is the syntax for this?
  • Open question: Can this be added without breaking existing cache manifest parsers?
  • External Contact: W3C
• It should be possible to declare that certain resources are optional. If a resource is optional, a 404 response code for the resource would not invalidate the entire app cache.
  • This would retain the current atomicity of the existing application cache semantics, while allowing optional exceptions.
  • Action item: What is the syntax for this?
  • Open question: Can this be added without breaking existing cache manifest parsers?
  • External Contact: W3C
• There should be browser behavior to prompt the user to reload a page where the cache has updated.
  • External Contact: Browser Vendors

General Open Questions

What is a cache manifest group?

References

http://www.stevesouders.com/blog/2011/10/03/improving-app-cache/
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

In https://github.com/jquery-foundation/standards/blob/master/reports/TC39/2016-05.md there is a link to http://disnetdev.com/template-literal-revision/ which is a 404

We should have a document to collect a list of bugs we report to keep track of any work on them.

This document might include other bugs relative to a bug or feature we eventually discuss.

TC39 is currently discussing STC as an alternative solution to ES2015 Proper Tail Calls.

https://github.com/tc39/proposal-ptc-syntax

Here is a summary of what's happening:

This proposal involves including a new syntax to indicate whether a function is using Tail Call Optimization or not. That solves some implementation problems like performance and the fact it can expose security issues on Firefox the way it's implemented. The alternative suggested by some runtime implementors is removing the Tail Call Optimization in a next spec version, which sounds bad.

It's worth mentioning this feature came pre-staging process and it was released before it was implemented in any major runtime. Today that would require at least two runtimes to implement it before it reaches stage 4, where it becomes part of the specs.

My ideas on this proposal are mostly in sync with @getify, as the first desirable option is not adding any new syntax for it.

There's a strong resistance from Apple JSC against accepting and adopting STC](tc39/ecma262#535).

This issue is just informative, discussions on the future of the proposal should be handled on the proposal's repo. We can still use this issue for minor discussions, like: "what is tail call optimization?" or "what is proper tail calls?".

There's a feature I'm planning to propose to TC39 on the next meeting.

You can check it here with a rationale, use cases, examples and an initial spec.

The name is still in a bikeshedding process and the best alternative candidate so far is Object.enumerableKeys, etc.

Every feedback there is important, thanks!

I don't always want to cache the host page for my App Cache. Let me control this, and optionally NOT cache the host page.

The HTML Standard defines the concept of an inert subtree, it was pointed to by dialog to explain how it worked (you should not be able to interact with the non-dialog portions of the tree, they become 'inert'). There was at one point an attribute inert documented. By & large though dialog wasn't implemented and this bug was opened in early 2014. One result was that inert as an attribute was removed for lack of implementer interest and work began instead on exposing a stack of blocking elements to describe the dialog behavior. However, there are numerous cases spelled out in that bug (see comment #12 for some) which seem like they would not be covered. Rob Dodson from the chrome team wrote up this a few days ago. It seems there is a fair amount of support in the a11y community for reviving some easy to use inert concept, I'd like to get more involved in that, support the idea... Especially where we can do so by testing the waters with a prolyfill.

There is a prolyfill under the GoogleChrome github, but it would seem that it is currently not entirely complete with what a11y folks think it should do (I think it doesn't set aria-hidden for example). Can probably send a pull to get it in good shape as we agree what shape that is.

Anyone have thoughts on any of this?

It has been proposed that the appcache spec be removed from html 5.1 but to leave in html 5 quoted

Hello,

The WP chairs and HTML editors propose removing Application Cache from the
HTML5.1 specification.

This is a CFC to adopt this proposal to remove App Cache from HTML5.1 and
subsequent versions of HTML. If you have comments or concerns, please send
them to [email protected] no later than 26th May 2016. Positive responses
are preferred and encouraged, but silence will be taken as agreement with
the proposal.

The rationale for:

1. App Cache does not do what developers expect, and although it has
   multiple current implementations, browsers are turning to Service Worker as
   a more useful solution for offline caching and resource management.
2. The definition of App Cache will remain (unchanged) in HTML5, and browser
   vendors are unlikely to devote time and effort refining App Cache in future
   versions of HTML.
3. Removing App Cache from HTML5.1 will help developers avoid adopting a
   technology that is no longer being improved or enhanced, whilst leaving the
   HTML5 definition as the de facto specification for agents wishing to
   maintain compatibility.

The rationale against:

1. Web browsers will need to support App Cache for some time to come.
2. W3C should continue to define how App Cache implementation evolves and
   fits in with new work.

Léonie on behalf of the WP chairs and HTML editors.

Similar to:

https://developer.mozilla.org/En/DOM:document.elementFromPoint

There should be a getElementsFromPoint which will get all elements under a specific point. This will make drag-drop type code much much easer (without needing to hide the dragging element).

This was echoed in some quirksmode blog post which I can no longer find.

There is a call for consensus on removing the keygen element from the html 5.1 spec do to lack of implementation and only one available algorithm being outdated and insecure

w3c html issue: w3c/html#43
PR : w3c/html#354
firefox removal issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13518
whatwg issue: whatwg/html#102
TAG thread: https://lists.w3.org/Archives/Public/www-tag/2016May/0006.html

Sorry for the late notice on this but the deadline for the call for consensus is tonight

Hello, everyone!

If you do know already, I recently joined the Standards team on the jQuery Foundation and I'll represent the foundation on TC39, along with @rwaldron. If you need a quick introduction of myself, I'm the current project leader on QUnit and I've been involved with test262 for almost an year.

The main mission is to reestablish the communication with the members of the jQuery Foundation and the Web Dev communities.

While I'm not trying to reinvent the wheel, I believe we should reuse this project for meta conversations. That means I'll do a cleanup closing the current issues but they can be re-opened if you find them important to keep the conversation. The next step is to update the current readme with everything that comes necessary.

@dmethvin told me there's a lot of people from our projects that are interested to get involved with the development of JavaScript. That means we should have a strong channel for everyone to participate, with suggestions, questions, feedbacks and proposals. To make this meta-repo become a strong channel I need your participation. Everything and everyone are welcome to participate!

We can - and should - use this project for pre-proposals discussions, even if that means you have questions on how to make one and bring it to TC39. At the same time, this repo should not be a blocker for anything else, it's just a helping tool.

I want to improve this mission on communication and I'm open for new ideas, so if you have any feedback, please tell me! You can reach me out here on GitHub, and on irc and twitter as @leobalter and on email: [email protected]. Please prefer an open communication whenever it's possible.

The next TC39 meeting is a month ahead and we have time to bring new ideas to it. I'll open an issue on this repo to link to my next proposal which might work as an example.

This repo should not be restricted to TC39 and JavaScript only. In fact, we are open to discuss on any standards that might affect the Web Dev communities.

Opening for @vgalindo and @dontcallmedom who expressed that they would be willing to work with local meetups - I'm not sure if they have one in mind already or need assist in setting up a connection, but until we have that worked out, let's track it here.

jQuery created a lot of sugar selectors that make finding relevant elements easier. It is now recommending against using many of them as they take a slow path and cannot leverage querySelectorAll. Selectors Level 4 should capture the selectors most used by jQuery developers.

Action Items

• Identify what selectors in jQuery are in use and are currently not captured in Selectors Level 4

References

http://dev.w3.org/csswg/selectors4/

Introduction

Since the CSS Print Module was adopted by all modern browsers, the ability to style and print documents from the web was almost a reality. One major piece is still standing between bridging the web world with the print world and that is the control of the print headers and footers when a document is printed through a browser.

Currently in most browsers, when a document is printed from the web a default header and footer is attached to the printed document that contains the URL where the document was generated from and the date and time it was generated.

Although it is currently possible to "turn off" the default headers and footers through most of the print dialog screens that are viewed before printing, the common user does not know how or care to discover how to shut these off manually. This unfortunately has lead developers to continue supporting PDF integration with their websites so they can fully control the printing experience of their users.

Proposal

There are currently 2 potential solutions as I see it.

1. When a document that is generated using a CSS Media type of print, the standards should specify that the print headers and footers should be defaulted to "blank" or "none"
2. An addition could be proposed to the W3C Print Profile draft (http://www.w3.org/TR/css-print/) that enables implicit control over the headers and footers generated by the browser's print subsystem.

Conclusion

This is a relatively uncomplicated proposal, yet it's implementation could significantly reduce the amount of third party tools (plug-ins) required on many websites where print control is an issue.

There are a lot of developers using custom events in their code. Right now there is no way to be sure that your custom event names will be safe to use in the future as more native events get added.

Specific Suggestions

• Create a prefix similar to data- attributes.
• Choose at least one character that will never appear in a native event so developers can include this somewhere in their custom event names. The form foo:bar seems to be somewhat popular.

Ref w3c/html#507 (comment)

This to me is not so much about the longdesc attribute as much as the format of the html5 spec in general. The decision was made ( which i agree with ) to modularize the HTML spec and reference extension specs from it.

The main difference i see here is that this takes the modularization a step further as this is just an attribute it seems a bit much, to need to got to and reference another document, just for an attribute. I would like to hear others opinions on the usability of this pattern.

There has been some pretty heated discussion in the issue already i highly recommend reading up on.

The W3C draft touch event standard already has pretty widespread adoption and implementation. If nothing else, it uses interfaces and naming conventions that are consistent with the rest of the W3C event model.

http://www.w3.org/TR/touch-events/

Microsoft has defined a different model for its Windows 8/IE10 touch events that live in a vendor-specific namespace (MSPointerDown, MSPointerMove, etc.). As of now, IE10 has no implementation of the W3C touch events. Here's some info on the MS touch events:

http://blogs.msdn.com/b/ie/archive/2011/10/19/handling-multi-touch-and-mouse-input-in-all-browsers.aspx

As you can see, there is quite a bit of code required to handle both models, and the example is not a complete or generalized compatibility layer. Microsoft also requires a special "-ms-content-zooming: none" CSS property to be added to an element before it can use touch. jQuery and other libraries could try to map the Microsoft model into the W3C one but at first glance it seems like this would be difficult and inefficient. For example, Microsoft fires a separate MSPointerMove event for each touch point, but the W3C touchmove fires once and provides an array of active touch points.

Web developers would be best served if everyone could get along and use the same event model for touch events.

Generating random numbers is a very common task in any language. By looking at discussions on StackOverflow such as [1] and [2] and the relevant MDN page, it's clear that many developers would benefit from such method. Not that it's really hard to implement using Math.random() but other utility methods have been added to JavaScript to facilitate developers' life.

My preference would go to the version that includes both the boundaries. So, the implementation should be something like:

Math.randomInt = function(min, max) {
   return Math.floor(Math.random() * (max - min + 1)) + min;
};

Browsers implement event.which for mouse events, and many users rely on it, but it's not defined in DOM Events. There is a standard for event.button and event.buttons, but according to jQuery's source it seems like at least one browser treats event.button as event.buttons.