(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first browser-provided "menu/overlay" that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where content comes from the web developer but the presentation/styling/sizing comes from the browser (and ignores full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the rest of the page. So if the rest of the page is small, then the datalist may get awkwardly sized when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
Bug 1756203 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first browser-provided "menu/overlay" that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where content comes from the web developer but the presentation/styling/sizing comes from the browser (and ignores full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly sized when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first browser-provided "menu/overlay" that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where content comes from the web developer but the presentation/styling/sizing comes from the browser (and ignores full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where content comes from the web developer but the presentation/styling/sizing comes from the browser (and ignores full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where the overlay's content clearly comes from the web developer but the presentation/styling/sizing comes from the browser (all of which ignore full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch, so let's just disregard that and focus on the other examples where the overlay's content clearly comes from the web developer but the presentation/styling/sizing comes from the browser (all of which ignore full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI example: `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - input datalist - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the datetime dropdown/picker - alert()/prompt() popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - the `<input type="text">` datalist dropdown - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the <input type="datetime"> dropdown/picker - JS `alert()`/`prompt()` popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - the `<input type="text">` datalist dropdown - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the <input type="datetime"> dropdown/picker - JS `alert()`/`prompt()` popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, which a user might reach for when using Firefox or any-application-at-all for the first time and noticing the text is too small; though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - the `<input type="text">` datalist dropdown - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the <input type="datetime"> dropdown/picker - JS `alert()`/`prompt()` popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, which a user might reach for when using Firefox or any-application-at-all for the first time and noticing the UI text is too small; though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default size of the content in the rest of the page. So if the rest of the page is small and the datalist is reasonably-sized, then the datalist may get awkwardly large when the user scales the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - the `<input type="text">` datalist dropdown - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the <input type="datetime"> dropdown/picker - JS `alert()`/`prompt()` popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, which a user might reach for when using Firefox or any-application-at-all for the first time and noticing the UI text is too small; though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default size of a datalist is unrelated to the (web-developer-specified) default sizes of the various content in the rest of the page. So if the rest of the page is small and the datalist is default-sized, then the datalist may get awkwardly large when the user scales to be able to read the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.
(In reply to Nic Steenhout from comment #14) > For what it's worth, I think approaching this like contextual menus available on right click is, forgive the pun, lacking Vision. Sure -- I used that since it was the first other browser-provided "menu/overlay" that appears over web content (with the same sized text as the datalist) that I could think of. But I admit that one's a bit of a stretch (users aren't likely to consider context-menus to be full-page-zoomable), so let's just disregard that and focus on the other examples where the overlay's **content** clearly comes from the web developer but the **presentation/styling/sizing** comes from the browser (and all of these happen to ignore full-page-zoom in all browsers I think): - the `<input type="text">` datalist dropdown - the `title` i.e. tooltip attribute (I just thought of that one). E.g. in this data-URI testcase (loadable by copypasting this into your URL bar and hitting enter) `data:text/html,<div title="I am a tooltip">Hover me to show tooltip` - the `<input type="datetime">` dropdown/picker - JS `alert()`/`prompt()` popups - maybe others we haven't thought of yet. > Don't put onus on the user to make sure their OS settings are right. Don't make them think. To be clear, I'm not saying "when a user encounters a too-small datalist, they should go in and reconfigure their OS settings". I was saying that all of the UI in the above list is (or should be) styled to be **as big as other important pieces of browser frontend UI** (e.g. menus, tab-titles, the URL bar itself) which the user **quite-rightly should expect to be able to read**. If that text is **all** too small, then that's a bigger problem that I'd imagine we'd want to help users fix across the board, rather than just providing a band-aid for one tiny piece of UI. (And OS settings is one existing way to fix that, which a user might reach for when using Firefox or any-application-at-all for the first time and noticing the UI text is too small; though maybe we need something in Firefox preferences as well? I'm not sure.) > datalist, and other elements that are loaded in a page should scale relative to the rest of the page, when a user needs/requires it. That's one option here, but as my testcase 2 shows, that's a bit awkward because the default sizes of these things are unrelated to the (web-developer-specified) default sizes of the various content in the rest of the page. So if the rest of the page is small and the datalist is default-sized, then the datalist may get awkwardly large when the user scales to be able to read the rest of the page. Maybe that's fine? But it's a bit of a strange wart, at least.