In this week’s roundup: Internet Explorer finds its way into Edge, Google Search Console touts a new speed report, and Firefox gives Facebook’s notification the silent treatment.

Let’s get into the news!

Edge browser with new Internet Explorer mode launches in January

Microsoft expects to release the new Chromium-based Edge browser on January 15, on both Windows and macOS. This browser includes a new Internet Explorer mode that allows Edge to automatically and seamlessly render tabs containing specific legacy content (e.g., a company’s intranet) using Internet Explorer’s engine instead of Edge’s standard engine (Blink).

Here’s a sped-up excerpt from Fred Pullen’s presentation that shows the new Internet Explorer mode in action:

(via Kyle Pflug)

Speed report experimentally available in Google Search Console

The new Speed report in Google’s Search Console shows how your website performs for real-world Chrome users (both on mobile and desktop). Pages that “pass a certain threshold of visits” are categorized into fast, moderate, and slow pages.

Tip: After fixing a speed issue, use the “Validate fix” button to notify Google Search. Google will verify the fix and re-index the pages if the issue is resolved.

(via Google Webmasters)

Facebook’s notification prompt will disappear in Firefox

Firefox will soon start blocking notification prompts on websites that request the notification permission immediately on page load (Facebook does this). Instead of the prompt, a small “speech balloon” icon will be shown in the URL bar.

Websites will still be able to show a notification prompt in Firefox as long as they request permission in response to a user interaction (a click, tap, or key press).

(via Marcos Càceres)

More news…

Read more news in my weekly newsletter for web developers. Pledge as little as $2 per month to get the latest news from me via email every Monday.

More News →

The post Weekly Platform News: Internet Explorer Mode, Speed Report in Search Console, Restricting Notification Prompts appeared first on CSS-Tricks.

from CSS-Tricks https://css-tricks.com/weekly-platform-news-internet-explorer-mode-speed-report-in-search-console-restricting-notification-prompts/…

Erik Kennedy’s course Learn UI Design is open for enrollment for less than a week. Disclosure, that link is our affiliate link. I’m linking to it here because I think this is worthy of your time and money if you’re looking to become a good UI designer.

I think of Erik sorta like the Wes Bos of design teaching. He really gets into the nitty-gritty and the why of good design. Design is tricky in that way. Adjusting some colors, spacing, and lines and stuff can feel so arbitrary at times. But you still have a sense for good and bad. The trick is honing your eye for spotting what is bad in a design and how to fix it. Erik excels at teaching that.

The course is a thousand bucks. Not very cheap. Personal lessons double that. It’s reasonable for you to have some questions.

Yes, it’s pro-quality. Yes, it’s 20 hours of video. Yes, you have lifetime access and can complete it on your own schedule. Yes, students get design jobs after completing it. Yes, there’s a student community with 1,000+ folks. Yes, you can use Sketch or Figma.

It’s a lot. It’s very modern and made to teach you how to be a designer in today’s world. So no, it’s not free or even inexpensive — but it’s good.

Direct Link to Article — Permalink

The post Learn UI Design appeared first on CSS-Tricks.

from CSS-Tricks http://bit.ly/2KmoKAB…

The world of web development has always had a gap between the design-to-development handoff. Ambitious designers want the final result of their effort to look unique and beautiful (and true to their initial vision), whereas many developers find more value in an outcome that is consistent, dependable, and rock solid (and easy to code). This dynamic can result in sustained tension between the two sides with both parties looking to steer things their own way.

While this situation is unavoidable to some extent, new front-end technology can play a role in bringing the two sides closer together. One such technology is CSS grid. This post explores how it can be used to write CSS styles that match design layouts to a high degree of fidelity (without the headache!).

A common way that designers give instructions to front-end developers is with design mockups (by mockups, we’re talking about deliverables that are built in Sketch, XD, Illustrator, Photoshop etc). All designers work differently to some degree (as do developers), but many like to base the structure of their layouts on some kind of grid system. A consistent grid system is invaluable for communicating how a webpage should be coded and how it should respond when the size of the user’s screen differs from the mockup. As a developer, I really appreciate designers who take the trouble to adopt a well thought-out grid system.

A 12-column layout is particularly popular, but other patterns are common as well. Software like Sketch and XD makes creating pages that follow a preset column layout pretty easy — you can toggle an overlay on and off with the click of a button.

Once a grid system is implemented, most design elements should be positioned squarely within it. This approach ensures that shapes line up evenly and makes for a more appealing appearance. In addition to being visually attractive, a predictable grid gives developers a distinct target to shoot for when writing styles.

Unfortunately, this basic …

In my germinating years, the general advice was this:

<ul>
  <li><span>List item</span></li>
  <!-- ... -->
</ul>

li { color: red; } /* bullet */
li span (color: black; } /* text */

Not terrible, but not great. You’re “resetting” everything at the span level, so it gets more complicated the more you do.

Things are getting much easier. Let’s take a walk through this world getting more modern as we go.

---

An alternative was to rip off the default list styling and replace it with a pseudo-element.

ul {
  list-style: none;
}

li::before {
  content: "• ";
  color: red;
}

If we need to count, we could do that with CSS counters.

ol {
  list-style: none;
  counter-reset: my-awesome-counter;
}

ol li {
  counter-increment: my-awesome-counter;
}

ol li::before {
  content: counter(my-awesome-counter) ". ";
  color: red;
}

---

Quick aside here: this doesn’t help with the color, but you can specify what character to use for the bullet by setting a string, like:

ul {
  list-style-type: '✽ ';
}

This is as of Firefox 39 (2015) and Chrome 79 (which comes out Dec 9, 2019).

For ordered lists, there is a ton of language-specific options. And those language styles work for CSS counters as well, which you can learn more about in Hui Jing’s deep dive.

See the Pen
Random CSS counters playground by Chen Hui Jing (@huijing)
on CodePen.

---

But all the while, we only wanted to select the stupid bullet (or whatever it is) and style it. Now we are starting to be able to do just that.

As of Firefox 68 (July 2019), you can do like:

li::marker {
  color: red;
  content: "►";
}

…which, as you can see, changes the color and the bullet thing That is definitely the cleanest and easiest way to go, so it’s nice to see progress.

Tejas demonstrates:

See the Pen
::marker example by Tejas (@tejask)
on CodePen.

Manuel Matuzović notes that if you set an element to a list-item display type, you …

I learned something about percentage-based (%) padding today that I had totally wrong in my head! I always thought that percentage padding was based on the element itself. So if an element is 1,000 pixels wide with padding-top: 50%, that padding is 500 pixels. It’s weird having top padding based on width, but that’s how it works — but only sorta. The 50% is based on the parent element’s width, not itself. That’s the part that confused me.

The only time I’ve ever messed with percentage padding is to do the aspect ratio boxes trick. The element is of fluid width, but you want to maintain an aspect ratio, hence the percentage padding trick. In that scenario, the width of the element is the width of the parent, so my incorrect mental model just never mattered.

It doesn’t take much to prove it:

See the Pen
% padding is based on parent, not itself by Chris Coyier (@chriscoyier)
on CodePen.

Thanks to Cameron Clark for the email about this:

The difference is moot when you have a block element that expands to fill the width of its parent completely, as in every example used in this article. But when you set any width on the element other than 100%, this misunderstanding will lead to baffling results.

They pointed to this article by Aayush Arora who claims that only 1% of developers knew this.

The post Oh Hey, Padding Percentage is Based on the Parent Element’s Width appeared first on CSS-Tricks.

from CSS-Tricks https://css-tricks.com/oh-hey-padding-percentage-is-based-on-the-parent-elements-width/…

Woah, I didn’t see this coming! The HTTP Archive dropped this big “state of the web” report called Web Almanac with guest writers exploring data from 5.8 million websites.

Una Kravetz and Adam Argyle wrote the CSS chapter. The point is to squeeze a digestible amount of insight out of a mountain’s worth of data. So there is some irony here with me squeezing in my thoughts about this chapter for an even quicker read, but hey, here we go.

• 83% of sites make use of rgba() but only 22% use rgb(). That entirely makes sense to me, as rgb() isn’t a particularly useful color format, if you ask me. It’s the “a” (alpha) that gives the format the ability control transparency, which is only recently available in the most popular format, Hex, in the form of 8-Digit Hex Codes. But even then, it isn’t as nice as rgba(). hsla() is arguably the nicest color format.
• Definitely not surprising that white and black are the two most popular named colors. I use them, by name, a lot. I even change CSS commits to use white instead of #FFF and black instead of #000 because I think there is less mental overhead to it.
• em is twice as popular as rem. Wow. I’m a rem guy myself, just because I find it less finicky and more predictable. In theory, I still like the idea of px at the Root, rem for Components, and em for Text Elements, but I’m not sure I’ve ever pulled it off that cleanly.
• Classes are by far the leader in selector types. Factoring how many are used, they have over a 10x lead over anything else. I like to see that. They have a low-but-not-too-low specificity value. They have nice APIs for manipulating them. Their entire purpose is to be a styling hook. They are element-agnostic. It’s just the right way to do styling. The flatter you keep styles, the less headaches you’ll have., A little more surprisingly to me

…