davatron5000

The State of Container Queries

tl;dr Developers would like the idea to style components based on a parent's width rather than depend solely on the viewport media query. This would allow modular components to style themselves while being agnostic to the viewport.

There is currently a lot of developer interest in getting a feature like Container Queries (née "Element Queryies") shipped in a browser.

2-min Catchup

Here are official'ish documents to outline the developer community's desires.

fahimbabarpatel

NOTE -

• Remove -h option if you are doing operation on same machine
• Remove -u , -p option if your database don't have username and password

Binary

Import database

mongorestore -h IP:port -d DB_Name -u user_name -p password <input db directory>

Integralist

const flattenTco = ([first, ...rest], accumulator) => 
  (first === undefined)
    ? accumulator
    : (Array.isArray(first))
      ? flattenTco([...first, ...rest])
      : flattenTco(rest, accumulator.concat(first))
  
const flatten = (n) => flattenTco(n, []);
  
console.log(flatten([[1,[2,[[3]]]],4,[5,[[[6]]]]]))

leocomelli

GIT

Estados

• Modificado (modified);
• Preparado (staged/index)
• Consolidado (comitted);

Ajuda

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

okunishinishi

#Delete local tags.
git tag -l | xargs git tag -d
#Fetch remote tags.
git fetch
#Delete remote tags.
git tag -l | xargs -n 1 git push --delete origin
#Delete local tasg.
git tag -l | xargs git tag -d

jaicab

.video-container {
  position: relative;
  padding-bottom: 56.25%; /*16:9*/
  padding-top: 30px; 
  height: 0; 
  overflow: hidden;
}
 
.video-container iframe,
.video-container object,

rxaviers

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

eCosinus

    var addContact = document.querySelector("#add-contact");
    if (addContact) {
        addContact.onclick = function () {
            var newContact = new MozActivity({
                name: "new", // Possibly add-contact in future versions
                data: {
                    type: "webcontacts/contact",
                    params: { // Will possibly move to be direct properties under "data"
                        givenName: "Robert",
                        lastName: "Nyman",

leostratus

An ongoing project to catalogue all of these sneaky, hidden, bleeding edge selectors as I prepare my JSConf EU 2012 talk.

Everything is broken up by tag, but within each the selectors aren't particularly ordered.

I have not tested/verified all of these. Have I missed some or got it wrong? Let me know. - A

A friendly reminder that you may need to set this property on your target/selected element to get the styling results you want:

-webkit-appearance:none;