diff --git a/files/en-us/web/opensearch/index.html b/files/en-us/web/opensearch/index.html index 9f5fa936004ad5f..448e4fa125496ca 100644 --- a/files/en-us/web/opensearch/index.html +++ b/files/en-us/web/opensearch/index.html @@ -16,7 +16,7 @@
Firefox also supports additional features not in the OpenSearch standard, such as search suggestions and the <SearchForm>
element. This article focuses on creating OpenSearch-compatible search plugins that support these additional Firefox features.
OpenSearch description files can be advertised as described in Autodiscovery of search plugins, and can be installed programmatically as described in Adding search engines from web pages.
+OpenSearch description files can be advertised as described in Autodiscovery of search plugins, and can be installed programmatically as described in Adding search engines from web pages.
URI of an icon for the search engine. When possible, include a 16×16 image of type image/x-icon
(such as /favicon.ico
) and a 64×64 image of type image/jpeg
or image/png
.
The URI may also use the data:
URI scheme. (You can generate a data:
URI from an icon file at The data:
URI kitchen.)
The URI may also use the data:
URI scheme. (You can generate a data:
URI from an icon file at The data:
URI kitchen.)
<Image height="16" width="16" type="image/x-icon">https://example.com/favicon.ico</Image> <!-- or --> @@ -59,7 +59,7 @@OpenSearch description file
Note: For icons loaded remotely (that is, from- +https://
URIs as opposed todata:
URIs), Firefox will reject icons larger than 10 kilobytes.
template
attribute indicates the base URL for the search query.In Firefox, an icon change in the search box indicates there's a provided search plugin. (See image, the green plus sign.) Thus if a search box is not shown in the user's UI, they will receive no indication. In general, behavior varies among browsers.
-Content-Type: application/opensearchdescription+xml
.template
URL must be escaped as &
, and tags must be closed with a trailing slash or matching end tag.xmlns
attribute is important — without it you could get the error message "Firefox could not download the search plugin".text/html
URL — search plugins including only Atom or RSS URL types (which is valid, but Firefox doesn't support) will also generate the "could not download the search plugin" error.text/html
URL — search plugins including only Atom or RSS URL types (which is valid, but Firefox doesn't support) will also generate the "could not download the search plugin" error.In terms of selector performance, less specific selectors are faster than more specific ones. For example, .foo {}
is faster than .bar .foo {}
because when the browser finds .foo
, in the second scenario, it has to walk up the DOM to check if .foo
has an ancestor .bar
. The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing.
If you measure the time it takes to parse CSS, you'll be amazed at how fast browsers truly are. The more specific rule is more expensive because it has to traverse more nodes in the DOM tree - but that extra expense is generally minimal. Measure first. Optimize as needed. Specificity is likely not your low hanging fruit. When it comes to CSS, selector performance optimization, improvements will only be in microseconds. There are other ways to optimize CSS, such as minification, and separating deferred CSS into non-blocking requests by using media queries.
+If you measure the time it takes to parse CSS, you'll be amazed at how fast browsers truly are. The more specific rule is more expensive because it has to traverse more nodes in the DOM tree - but that extra expense is generally minimal. Measure first. Optimize as needed. Specificity is likely not your low hanging fruit. When it comes to CSS, selector performance optimization, improvements will only be in microseconds. There are other ways to optimize CSS, such as minification, and separating deferred CSS into non-blocking requests by using media queries.
The logic behind pairing these hints is because support for dns-prefetch is better than support for preconnect. Browsers that don’t support preconnect will still get some added benefit by falling back to dns-prefetch. Because this is an HTML feature, it is very fault-tolerant. If a non-supporting browser encounters a dns-prefetch hint—or any other resource hint—your site won’t break. You just won’t receive the benefits it provides.
-Some resources such as fonts are loaded in anonymous mode. In such cases you should set the crossorigin attribute with the preconnect hint. If you omit it, the browser will only perform the DNS lookup.
+Some resources such as fonts are loaded in anonymous mode. In such cases you should set the crossorigin attribute with the preconnect hint. If you omit it, the browser will only perform the DNS lookup.
Note: For much more information on improving startup performance, read Optimizing startup performance.
-On the same note, notice that locally-cached, static resources can be loaded much faster than dynamic data fetched over high-latency, low-bandwidth mobile networks. Network requests should never be on the critical path to early application startup. Local caching/offline apps can be achieved via Service Workers. See Making PWAs work offline with Service workers for a guide as to how.
+On the same note, notice that locally-cached, static resources can be loaded much faster than dynamic data fetched over high-latency, low-bandwidth mobile networks. Network requests should never be on the critical path to early application startup. Local caching/offline apps can be achieved via Service Workers. See Making PWAs work offline with Service workers for a guide as to how.
The MDN Web Performance Learning Area contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance:
PerformanceFrameTiming
interface provides frame timing data about the browser's event loop.<picture>
Element<video>
Element<source>
Element<img> srcset
attribute
+ <img> srcset
attribute
@@ -207,7 +207,7 @@ JavaScript
@@ -233,7 +233,7 @@When a user requests a web site or application, to populate the browser the user agent goes through a series of steps, including a {{glossary('DNS')}} lookup, {{glossary('TCP handshake')}}, and SSL negotiation, before the user agent makes the actual request and the servers return the requested assets. The browser then parses the content received, builds the DOM, CSSOM, accessibility, and render trees, eventually rendering the page. Once the user agent stops parsing the document, the user agent sets the document readiness to interactive. If there are deferred scripts needing to be parsed, it will do so, then fire the DOMContentLoaded, after which the readiness is set to complete. The Document can now handle post-load tasks, after which point the document is marked as completely loaded.
+When a user requests a web site or application, to populate the browser the user agent goes through a series of steps, including a {{glossary('DNS')}} lookup, {{glossary('TCP handshake')}}, and SSL negotiation, before the user agent makes the actual request and the servers return the requested assets. The browser then parses the content received, builds the DOM, CSSOM, accessibility, and render trees, eventually rendering the page. Once the user agent stops parsing the document, the user agent sets the document readiness to interactive. If there are deferred scripts needing to be parsed, it will do so, then fire the DOMContentLoaded, after which the readiness is set to complete. The Document can now handle post-load tasks, after which point the document is marked as completely loaded.
let navigationTimings = performance.getEntriesByType('navigation');diff --git a/files/en-us/web/performance/optimizing_startup_performance/index.html b/files/en-us/web/performance/optimizing_startup_performance/index.html index 4237dc22079f0ec..b080ff5f44ba7fe 100644 --- a/files/en-us/web/performance/optimizing_startup_performance/index.html +++ b/files/en-us/web/performance/optimizing_startup_performance/index.html @@ -14,7 +14,7 @@
Regardless of platform, it's always a good idea to start up as quickly as possible. Since that's a universal issue, we won't be focusing on it too much here. Instead, we're going to look at a more important issue when building Web apps: starting up as asynchronously as possible. That means not running all your startup code in a single event handler on the app's main thread.
-Instead, you should write your code so that your app creates a Web worker that does as much as possible in a background thread (for example, fetching and processing data.) Then, anything that must be done on the main thread (such as user events and rendering UI) should be broken up into small pieces so that the app's event loop continues to cycle while it starts up. This will prevent the app, browser, and/or device from appearing to have locked up.
+Instead, you should write your code so that your app creates a Web worker that does as much as possible in a background thread (for example, fetching and processing data.) Then, anything that must be done on the main thread (such as user events and rendering UI) should be broken up into small pieces so that the app's event loop continues to cycle while it starts up. This will prevent the app, browser, and/or device from appearing to have locked up.
Why is it important to be asynchronous? Other than the reasons suggested above, consider the impact of a non-responsive page or user interface. The user is unable to cancel if they launched your app by mistake. If the app is being run in a browser, it's possible the user may get an "unresponsive app" or "slow script" notification. You should present some kind of interface, such as a progress bar, so that the user knows how much longer they'll need to wait while your app starts up.
@@ -24,7 +24,7 @@On the other hand, however, it can get tricky when you're porting an existing app to the Web. A desktop application doesn't need to be written in an asynchronous fashion because usually the operating system handles that for you, or the app is the only thing that matters which is currently running, depending on the operating environment. The source application might have a main loop that can easily be made to operate asynchronously (by running each main loop iteration separately); startup is often just a continuous, monolithic procedure that might periodically update a progress meter.
-While you can use Web workers to run even very large, long-duration chunks of JavaScript code asynchronously, there's a huge caveat that: workers don't have access to WebGL or audio, and they can't send synchronous messages to the main thread, so you can't even proxy those APIs to the main thread. This all means that unless you can easily pull out the "pure calculation" chunks of your startup process into workers, you'll wind up having to run most or all of your startup code on the main thread.
+While you can use Web workers to run even very large, long-duration chunks of JavaScript code asynchronously, there's a huge caveat that: workers don't have access to WebGL or audio, and they can't send synchronous messages to the main thread, so you can't even proxy those APIs to the main thread. This all means that unless you can easily pull out the "pure calculation" chunks of your startup process into workers, you'll wind up having to run most or all of your startup code on the main thread.
However, even code like that can be made asynchronous, with a little work.
@@ -74,7 +74,7 @@A default baseline to reduce bounce rate is to achieve Time to Interactive under 5 seconds in 3G/4G, and under 2 seconds for subsequent loads. However, based on the specific goals and content of your site, you might choose to focus on other metrics.
-For a text-heavy site such as a blog or a news site, the First Contentful Paint metric could reflect more closely the user behavior. (i.e. How fast can users start reading), which will inform file specific budgets (e.g. Font size), and their optimizations. (e.g. Using font-display to improve Perceived Performance).
+For a text-heavy site such as a blog or a news site, the First Contentful Paint metric could reflect more closely the user behavior. (i.e. How fast can users start reading), which will inform file specific budgets (e.g. Font size), and their optimizations. (e.g. Using font-display to improve Perceived Performance).
-The ultimate value of a Performance Budget is to correlate the impact of Performance on business or product goals. When defining metrics, you should focus on User Experience, which will dictate not only the bounce or conversion rate but how likely is that user to return.
+The ultimate value of a Performance Budget is to correlate the impact of Performance on business or product goals. When defining metrics, you should focus on User Experience, which will dictate not only the bounce or conversion rate but how likely is that user to return.
A2HS is supported in all mobile browsers, except iOS webview. It's also supported in some Chromium desktop browsers.
-Firefox has had mobile support since v58.
+Firefox has had mobile support since v58.
See caniuse.com for exact details.
diff --git a/files/en-us/web/progressive_web_apps/developer_guide/installing/index.html b/files/en-us/web/progressive_web_apps/developer_guide/installing/index.html index b1d9b6ff3c87663..9b317a3a46dd414 100644 --- a/files/en-us/web/progressive_web_apps/developer_guide/installing/index.html +++ b/files/en-us/web/progressive_web_apps/developer_guide/installing/index.html @@ -73,7 +73,7 @@On Apple's iOS (including iPhoneOS and iPadOS), the Safari browser built into the device has some support for web applications, including support for the add to home screen feature. To add a web app to the home screen (also known as the launcher or springboard), tap the sharing button () at the bottom of the screen:
+On Apple's iOS (including iPhoneOS and iPadOS), the Safari browser built into the device has some support for web applications, including support for the add to home screen feature. To add a web app to the home screen (also known as the launcher or springboard), tap the sharing button () at the bottom of the screen:
diff --git a/files/en-us/web/progressive_web_apps/introduction/index.html b/files/en-us/web/progressive_web_apps/introduction/index.html index 33310526225ceaf..16883624a80e30b 100644 --- a/files/en-us/web/progressive_web_apps/introduction/index.html +++ b/files/en-us/web/progressive_web_apps/introduction/index.html @@ -43,14 +43,14 @@There are some key principles a web app should try to observe to be identified as a PWA. It should be:
Offering these features and making use of all the {{anch("Advantages of web applications", "advantages")}} offered by web applications can create a compelling, highly flexible offering for your users and customers.
diff --git a/files/en-us/web/progressive_web_apps/responsive/graphics_for_responsive_sites/index.html b/files/en-us/web/progressive_web_apps/responsive/graphics_for_responsive_sites/index.html index f8d3b74d0c953f6..49763e0e5998da3 100644 --- a/files/en-us/web/progressive_web_apps/responsive/graphics_for_responsive_sites/index.html +++ b/files/en-us/web/progressive_web_apps/responsive/graphics_for_responsive_sites/index.html @@ -20,9 +20,9 @@In general, you will use mostly the same graphical assets for different layouts in a responsive design, but you may well include slightly different ones dependant on context. For example, if your desktop layout includes a large header graphic and several programmatic graphics (e.g. CSS3 drop shadows and gradients), you may want to simplify or remove certain assets for the site's mobile layout, or even provide smaller assets to suit the smaller screen better. This is because in general mobile devices will have less processing power and bandwidth available, so you want to reduce the processing and downloads. In addition, mobile devices have smaller screen sizes, so it makes sense to reduce visual clutter on a mobile layout.
-CSS media queries allow us to serve different CSS rules dependant on viewport dimensions, and you should consider using mobile first media queries where possible. This means that the default layout before any media queries are encountered in the CSS is the small screen/mobile layout, not the wide screen/desktop layout. So when the page is loaded on a mobile device, the mobile will only download the mobile assets, and not the desktop resource assets.
+CSS media queries allow us to serve different CSS rules dependant on viewport dimensions, and you should consider using mobile first media queries where possible. This means that the default layout before any media queries are encountered in the CSS is the small screen/mobile layout, not the wide screen/desktop layout. So when the page is loaded on a mobile device, the mobile will only download the mobile assets, and not the desktop resource assets.
-Making HTML <img>
s responsive is not as easy, as there is currently no native mechanism to serve different HTML images depending on context. There are a number of workarounds, but none of them are perfect right now. For an overview of what's available, read Choosing a responsive image solution.
Making HTML <img>
s responsive is not as easy, as there is currently no native mechanism to serve different HTML images depending on context. There are a number of workarounds, but none of them are perfect right now. For an overview of what's available, read Choosing a responsive image solution.
This is the 14th and last section of Part I of the CSS Getting Started tutorial. Many pages in this tutorial focused on the CSS properties and values, as well as how you use these to specify the way that content displays.
+This is the 14th and last section of Part I of the CSS Getting Started tutorial. Many pages in this tutorial focused on the CSS properties and values, as well as how you use these to specify the way that content displays.
Note: This snippet only works on Firefox since it erroneously increments the CSS counter for fix-position elements. It should not work in other browsers. See issue on css3-page.
+Note: This snippet only works on Firefox since it erroneously increments the CSS counter for fix-position elements. It should not work in other browsers. See issue on css3-page.
See solutions to these challenges.
+See solutions to these challenges.
If you had difficulty understanding this page, or if you have other comments about it, please contribute to its Discussion page.
-So far, all the style rules in this tutorial have been specified in files. The rules and their values are fixed. The next page describes how you can change rules dynamically by using a programming language: JavaScript.
+So far, all the style rules in this tutorial have been specified in files. The rules and their values are fixed. The next page describes how you can change rules dynamically by using a programming language: JavaScript.
diff --git a/files/en-us/web/progressive_web_apps/responsive/mobile_first/index.html b/files/en-us/web/progressive_web_apps/responsive/mobile_first/index.html index 777fc9be6a4a1b8..c25493389b3a696 100644 --- a/files/en-us/web/progressive_web_apps/responsive/mobile_first/index.html +++ b/files/en-us/web/progressive_web_apps/responsive/mobile_first/index.html @@ -24,7 +24,7 @@The Web offers a wide variety of APIs to perform various useful tasks. These can be accessed using JavaScript code, and let you do anything from making minor adjustments to any {{domxref("window")}} or {{domxref("element")}}, to generating intricate graphical and audio effects using APIs such as WebGL and Web Audio.
+The Web offers a wide variety of APIs to perform various useful tasks. These can be accessed using JavaScript code, and let you do anything from making minor adjustments to any {{domxref("window")}} or {{domxref("element")}}, to generating intricate graphical and audio effects using APIs such as WebGL and Web Audio.
Each individual interface across all APIs is listed in the index.
-There's also a listing of all available events in the event reference.
+There's also a listing of all available events in the event reference.