See https://news.ycombinator.com/item?id=22206663 for discussion.
239 karma · joined August 27, 2009
(2) Having said that, as a request to everybody for future text-based creations, could we please stop referring to non-ASCII text as "ASCII". Using characters that aren't in ASCII really shouldn't be referred to as ASCII. Pretty please.
(3) The more generic label of "text QR" or "text-based QR" would be better, in my opinion. In this particular situation, saying "Unicode text QR" or "Unicode QR" would also be appropriate.
"Among high school students, during 2011–2018, no significant trend in the reported use of any tobacco product overall was observed (Figure 2). However, changes were observed for individual tobacco products over this period. A significant nonlinear increase in current e-cigarette use occurred from 2011 (1.5%) to 2018 (20.8%). During 2011–2018, significant linear declines in combustible tobacco product use (from 21.8% to 13.9%) and ≥2 tobacco product use (from 12.0% to 11.3%) occurred; by product type, significant linear declines occurred for cigars (from 11.6% to 7.6%), smokeless tobacco (from 7.9% to 5.9%), and pipe tobacco (from 4.0% to 1.1%). A significant nonlinear decline was observed for cigarettes (from 15.8% to 8.1%). A significant nonlinear change during 2011–2018 was observed for hookahs (from 4.1% to 4.1%).
Among middle school students, no significant change in use of any tobacco product overall occurred during 2011–2018 (Figure 3). However, changes for individual tobacco products were observed. A significant nonlinear increase in e-cigarette use occurred (from 0.6% to 4.9%) during 2011–2018. A significant linear decline was observed for combustible tobacco product use (from 6.4% to 3.3%), ≥2 tobacco products use (from 3.8% to 2.4%), cigarettes (from 4.3% to 1.8%), cigars (from 3.5% to 1.6%), smokeless tobacco (from 2.7% to 1.8%), and pipe tobacco (from 2.2% to 0.3%); a significant nonlinear change occurred for hookah smoking (from 1.0% to 1.2%)."
→ http://web4.cs.ucl.ac.uk/staff/D.Barber/textbook/091117.pdf
Aside:
⸰ Textbook homepage: http://web4.cs.ucl.ac.uk/staff/D.Barber/pmwiki/pmwiki.php?n=...
⸰ Online version homepage (should always contain link to latest revision): http://web4.cs.ucl.ac.uk/staff/D.Barber/pmwiki/pmwiki.php?n=...
⸰ Directory sorted by date: http://web4.cs.ucl.ac.uk/staff/D.Barber/textbook/?C=M;O=D
(1) Karabiner: https://pqrs.org/osx/karabiner/ → Cf. Kellen Mace, "Separate Trackpad & Mouse Natural Scrolling in Mac OS X" (2014) https://kellenmace.com/automate-trackpad-mouse-natural-scrol...
(2) Scroll Reverser: http://pilotmoon.com/scrollreverser/
Now, what they will do is explicitly write the company that has the registered logo -- requesting written approval for a particular context/usage. If they get that, then they will use the registered logo. But as the default case, "avoid as much as possible" is standard policy. Some are more afraid of legal matters than others. Whether this fear is justified is not as immediately relevant in this particular context, as is the existence of the fear itself and the consequences thus.
Cf. https://www.microsoft.com/en-us/legal/intellectualproperty/t...
"Poking fun" would be something along the lines of using the blue-screen-of-death screen as seen with previous networked computer icons in OS X. Whereas, in this instance, the visual representation is a very simple, generic "window" that is still distinctly different from any previously registered Microsoft Windows logos. To me, this instance appears to just be simply avoiding unnecessary use of a registered logo.
I could also get into it further, elaborating why textual registered trademarks may be considered easier to use for fair-use (used for informational purposes) versus registered graphical elements (i.e., logos), but I have no such desire.
This article is merely clickbait.
Some relevant excerpts from Mac OS X and iOS Internals: To the Apple's Core by Jonathan Levi:
From page 133: In 64-bit mode, there is such a huge amount of memory available anyway that it makes sense to follow the model used in other operating systems, namely to map the kernel’s address space into each and every process. This is a departure from the traditional OS X model, which had the kernel in its own address space, but it makes for much faster user/kernel transition (by sharing CR3, the control register containing the page tables).
From page 266: Still, unlike Windows or Linux, OS X applications in 32-bit (Intel) used to enjoy a largely unfettered address space with virtually no kernel reservation — that is, the kernel had its own address space. Apple has conformed, however, and in 64-bit mode OS X behaves more like its monolithic peers: the kernel/user address spaces are shared, unless otherwise stated (by setting the -no-shared-cr3 boot argument on Intel architectures). The same holds true in iOS, wherein XNU currently reserves the top 2 GB of the 4 GB address space (prior to iOS version 4 the separation was 3 GB user/1 GB kernel).
• Releases: http://www.apollo-core.com/knowledge.php?b=6
◦ FPGA image: http://www.apollo-core.com/bringup/apollo_mini_2000_83.jic
◦ phoenixinit: http://www.apollo-core.com/bringup/phoenixinit
• Some photos: http://www.apollo-core.com/bringup/
• Altera FPGA, etc. http://www.apollo-core.com/knowledge.php?b=3¬e=3120
Cf. http://www.guanotronic.com/~serge/papers/fc15-fonts.pdf & http://pet-portal.eu/files/articles/2011/fingerprinting/cros...
1. Knowing extremes and layout boundary conditions: You can reasonably test extremes of wide and condensed font metrics; it's not that hard.
2. Rigid designs: If you don't want to use the ambiguous system font, you don't have to; it doesn't change that. If you have a design that requires certain rigidity and inflexibility, you can have your explicitly imported web fonts and be happy.
3. Flexible designs: Be flexible and fluid. Be like water. Heck, there are slight unknowns with using any non-explicitly defined font. Using CSS generic-family identifiers (serif, sans-serif, cursive, fantasy, and monospace) have variation and are not guarantees, but you can still use them without much concern for layouts that are designed to be appropriately accommodating.
4. Native look and feel: If you want to achieve something closer to the native system look and feel, being able to use the system font from CSS helps you out immensely. For those that (1) design their layout to flow relatively nicely without being overly fixed or constrained and (2) want to have an appearance matching the system font, then it's great!
5. Testing: From my experience, this doesn't pose any significant testing issues. Besides testing artificial extremes of wide and condensed font metrics, practical testing across multiple environments isn't anything new. It's something that already gets done by any skilled front-end designer. Many shops will test across many browsers under may platforms anyway. Sites like http://browsershots.org, https://www.browserstack.com/screenshots, http://www.crossbrowsertool.com, http://www.browsershots.atm, https://www.browserling.com, http://dev.modern.ie/tools/screenshots/ and many others are out there for people who don't have or don't want to deal with the setup in-house to do testing. (You might have to supplement it with mobile devices in-house, sure.) You can easily cover 95% of the actually used environments (browsers/platforms) very explicitly, and for the environments you don't explicitly test for, at that point of successful testing, it's very likely there won't be an issue, and if there is an issue, it should be minor and not significantly matter. Be pragmatic.
Maybe someone's Linux distro is using a serif typeface, or a monospaced serif typeface, or a monospaced sans-serif typeface, or something more like Comic Sans (have seen this more than once) as their system font.
The point is, we can do better than what we have now with regard to the goal of making web applications approach the "native look and feel" more easily and more simply. It's a balance game; a balance between adding features like this (every feature adds a little bloat) that also potentially help eliminate bloat elsewhere in code (e.g., javascript to fingerprint the environment). Further, getting the system font is something that CSS should be able to know about without the aid of JavaScript; there are lots of simple forms and data entry "applications" that don't use any JavaScript (nor should they) and would benefit from a better presentation. Writing a native application for any platform, I want to get the system font, and not have to know or assume any qualities of what that font is. With typical native applications, the default font is intrinsic in the UI widgets your using, so you don't have to think about it. With the web, typically the default font is a "document font" and not the UI widget font, so you need to be able to have some sort of mechanism beyond the default font in order to get the system UI font.
In the scrolling case, I still don't see how it's "overriding the browser buttons", but rather having a JavaScript that advances to the next page on scroll.
In the scrolling scenario, my actual back and forward browser buttons behaved as expected — just for the pages (slides) I visited. No more, no less.