Contributing to Mozilla Developer Network (MDN)

Mendy Berger — Fri, 30 Oct 2020 15:11:09 +0000

I'm always looking for ways to both, give back to the #opensource community, and grow my expertise in software engineering.

I recently saw a post by Chris Mills about the need for contributors for Mozilla Developer Network (MDN), and since they have helped me out so much, I figured that this is a project that I would like to give back to.

So, I'm taking a challenge upon myself to make 8 quality contributions to any of the MDN projects in the next 2 months, about one contribution for every week.

I don't know how hard or easy this is going to be but I'm going to try my best.

I kicked it off with a contribution to browser-compat-data about MediaSession support in Firefox Desktop.

Twitter version of this post.

Simple and Tiny CSS Reset

Mendy Berger — Wed, 14 Oct 2020 03:50:47 +0000

I think that I found my new CSS reset, it's simple, tiny, and elegant

* {
  all: unset;
  display: revert;
}

I first unset all properties, but I need to revert display to the user-agent-stylesheet default otherwise all elements will be displayed, including elements that are not meant to be displayed like style, script, title, etc.

Making it just a little better

* {
    all: unset;
    display: revert;
    box-sizing: border-box;
}
[default-styles] {
    all: revert;
}

Why `box-sizing: border-box;`?

I just think that its easier to think of the element with its border as a block instead of thinking of just its content as a block.

Why `[default-styles]`?

You can add this attribute "default-styles" to any element that you want to revert the styles back to the default.
This is useful for elements that have default styles that might be useful in some cases, but in most cases, it would end up being overridden, like button, input, select, etc.

Fixing SVG problems

The all CSS property includes some SVG properties, and unsetting them means losing most of the power of SVG, so we need to exclude all SVG elements, this can be done easily by excluding the SVG namespace

@namespace svg "http://www.w3.org/2000/svg";
:not(svg|*) {
    all: unset;
    display: revert;
    box-sizing: border-box;
}
[default-styles] {
    all: revert;
}

Problem with custom-elements

This will override all styles in :host, making this approach hard to recommend when working with web components.

Please share your thoughts in the comments section, thanks 🙏

Input and JS dates

Mendy Berger — Tue, 15 Sep 2020 01:00:26 +0000

Making time related inputs work with local timezones - JavaScript

The problem

HTML supports multiple time-related input types like: time, date, week, month, and datetime-local. All this is great, however, there can be one small problem: we need a way to set the value of the input from a JavaScript Date object, as well as a way to get the value from the input into a date object.

Unless you're on GMT you should see that the hour in the input is different than in the p element

valueAsDate and valueAsNumber

The time-related inputs have a property named valueAsDate or valueAsNumber (some have both and some only one), which is a JavaScript Date object or a epoch timestamp number, great no? Well, no, not really, let me explain, the time-related inputs are always on UTC, that is, if the user enters say 9:00 AM in the input, valueAsDate will return 9:00 AM on UTC not local time, which unless you're on UTC will result in the time being a number of hours off.

Another problem that valueAsDate has, is that since some browsers don't support (at the time of this writing) some of the time-related inputs, valueAsDate is therefore also not supported which means that this won't work at all in those browsers instead of gracefully degrading.

Solution for timezone problem

A possible solution for the timezone problem with valueAsDate and valueAsNumber is to move the time with the offset of the current timezone from UTC, so that its actually in the wrong time (because JS Dates are always on UTC, not on local time), but will work to get the input to display the correct time (as mentioned that the input is always on UTC). And then, when we get the date out we can move the time back with the timezone offset.

When using this technique we have to be careful not to change the source date but to always first make a copy of the date and work on the copy.

JavaScript to HTML

let htmlDate = new Date(jsDate); // make a copy of the source date
htmlDate.setMinutes(htmlDate.getMinutes() + htmlDate.getTimezoneOffset());

input.valueAsDate = htmlDate; // Setting by date
// Or:
input.valueAsNumber = htmlDate.getTime(); // Setting by number

HTML to JavaScript

// make a copy of the source date
let jsDate = new Date(input.valueAsDate); // Getting by date
// Or:
let jsDate = new Date(input.valueAsNumber); // Getting by number

jsDate.setMinutes(jsDate.getMinutes() - jsDate.getTimezoneOffset());

Where to use `valueAsDate` or `valueAsNumber`.

Input type	`valueAsDate`	`valueAsNumber`
`datetime-local`	No ¹	Yes
`time`	Yes	Yes
`date`	Yes	Yes
`week`	Yes	Yes
`month`	Yes	No ²

¹ datetime-local doesn't have a valueAsDate property.

² The valueAsNumber property of the month input is not an epoch but the numbers of months since 1970.

However this only solves the timezone problem, not the browser compatibility problem

The solution

Since valueAsDate and valueAsNumber won't work in unsupported browsers we can't really use them, rather we'll need a way that can gracefully fallback when the input type isn't supported.

To get the value from a JavaScript Date object to the HTML input we can use the Date.toLocalString method that can get us the proper format for most of these inputs. (I found that the sv-SE locale is quite close to the HTML format.)

To get the value from HTML to a JavaScript Date can be a bit more tricky, JavaScript Date objects require both date and time down to the millisecond, there is no such a thing as a date-only or time-only JavaScript object, while datetime-local has both date and time information, none of the others have all the information to create a proper date just from the input, which means that if we want to get the information from a time-related input to a JavaScript Date we will need to provide the missing information another way.

type=datetime-local

Expected value

The expected value for the datetime-local input is yyyy-mm-ddThh:mm:ss.

JavaScript to HTML

We can use sv-SE but we'll have to replace the space between the date and time with a T to make it compatible with HTML.

If you have an input without seconds remove second: "2-digit".

input.value = date.toLocaleString("sv-SE", {
    year: "numeric",
    month: "2-digit",
    day: "2-digit",
    hour: "2-digit",
    minute: "2-digit",
    second: "2-digit"
}).replace(" ", "T");

HTML to JavaScript

Getting the value from a datetime-local input to a Date object is simple, just pass in input.value to a Date constructor, it will default to the local timezone.

new Date(input.value);

type=time

Expected value

The expected value for the time input is hh:mm:ss.

JavaScript to HTML

If you have an input without seconds remove second: "2-digit".

input.value = date.toLocaleString("sv-SE", {
    hour: "2-digit",
    minute: "2-digit",
    second: "2-digit"
});

HTML to JavaScript

To get a Date object from the time the user entered we will need a day in the following format yyyy-mm-dd to attach to the time.

Tip to get the day from a Date object you can use the same .toLocaleString options as type=date uses to get from JavaScript to HTML.

const day = "2020-01-01";
new Date(day + "T" + input.value);

type=date

Expected value

The expected value for the date input is yyyy-mm-dd.

JavaScript to HTML

input.value = date.toLocaleString("sv-SE", {
    year: "numeric",
    month: "2-digit",
    day: "2-digit"
});

HTML to JavaScript

The JavaScript Date object constructor has a weird rule, if it gets a date without a time it defaults to UTC instead of the local timezone.

To get around this we need to enter the time manually, I use 00:00 (12:00 AM) as here but you can change it to whatever time in the day you want.

new Date(input.value + "T00:00");

type=month

Expected value

The expected value for the month input is yyyy-mm.

JavaScript to HTML

input.value = date.toLocaleString("sv-SE", {
    year: "numeric",
    month: "2-digit"
});

HTML to JavaScript

As mentioned before (type=date) we'll need to add the missing parts (day in month, and time) manually.

new Date(input.value + "-01T:00:00");

type=week

Expected value

The expected value for the week input is yyyy-Www.

This one is not easy, .toLocaleString doesn't support getting weeks and I'm not aware of any way to create a Date object from week data, so the only way is to use the valueAsDate or valueAsNumber with the technique described above, resulting in limited browser support.

So if you do have any ideas that you think might make this cross platform please let me know.

DEV Community: Mendy Berger

Contributing to Mozilla Developer Network (MDN)

Simple and Tiny CSS Reset

Making it just a little better

Why box-sizing: border-box;?

Why [default-styles]?

Fixing SVG problems

Problem with custom-elements

Input and JS dates

Making time related inputs work with local timezones - JavaScript

The problem

valueAsDate and valueAsNumber

Solution for timezone problem

JavaScript to HTML

HTML to JavaScript

Where to use valueAsDate or valueAsNumber.

The solution

type=datetime-local

Expected value

JavaScript to HTML

HTML to JavaScript

type=time

Expected value

JavaScript to HTML

HTML to JavaScript

type=date

Expected value

JavaScript to HTML

HTML to JavaScript

type=month

Expected value

JavaScript to HTML

HTML to JavaScript

type=week

Expected value

Why `box-sizing: border-box;`?

Why `[default-styles]`?

Where to use `valueAsDate` or `valueAsNumber`.