178 karma · joined February 25, 2014
Software is often judged based on these UI/UX nuances, but the complexity of building a competent front-end system remains an undervalued part of the process.
The front-end team is usually (1) brought in too late in the game to provide effective feedback and (2) not given enough time to build.
When there's not front-end representation at early design reviews or at initial discussions on how APIs should work, then it's easy to forget things like form error handling.
Designs don't account for all possible states, services/APIs are in flux, until the very end.
Everything else is late, and then all of it has to get slapped together with duct tape and shipped in a few weeks. Performance and browser support be damned.
https://www.pantone.com/color-finder/14-0105-TPG
But you're right -- with a color dropper, I'm getting all kinds of results, typically a darker ~999281.
Two problems I see:
1. Where you have a heading you may want it and its associated content wrapped in a <section>. Where you have a separated paragraph you really do probably want a <p>.
So these newlines aren't always just replacing <div>s. The page has no structure except what can be derived from headings.
2. Wrapping everything in a <code> tag seems like it could cause issues. It would probably be better to use <main> and apply the clever one line of CSS mentioned in the post.
https://www.youtube.com/watch?v=DBcz_bGcHgk
After watching this video from Google, I think the future is web components + AOM[1].
This makes sense to me because:
1) Most web developers are already using frameworks (such as React) which can render web components.
2) We can't expect all web developers to be ARIA/WCAG/ADA experts — they're always going to be trying to write code that quickly/efficiently expresses their intent.
Once we get full buy-in and implementation in all browsers and screen readers, most web developers probably won't be using <button> much anymore.
Instead, they'll be using <framework-button>. The <framework-button> sets up all the appropriate ARIA properties/attributes, can restrict what slot content it accepts, and can present remaining issues as errors in the console.
Perhaps under the hood <framework-button> does indeed include a <button> in its Shadow DOM, or maybe it's a <span>.
Coupled with Houdini and some other emerging standards, I think AOM will finally make web components a viable option for most developers, and can solve the vast majority of accessibility issues we see today.
[1]: https://wicg.github.io/aom/explainer.html#motivating-use-cas...
> It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet
OP's suggestion is that the author should have used native HTML <button>, a simple solution that has worked since the beginning.
But you're right that it's not so elegant in reality:
You must remember to add type="button" attribute, otherwise clicking it could trigger page reload accidentally.
Most browsers still force <button> to retain its default display property. Within flowing text, it can never break naturally onto the next line, whereas an <a> link can.
It also can't be a flex or grid container in certain browsers, so you often need an inner element for proper spacing/positioning.
Note that the inner element would need to be a <span> not a <div> because <button> can only contain phrasing elements.
So one explanation is that natural selection has found a balance that yields benefits for the group.
Please consider making the default colors/fonts CSS variables in the :root so that they can be easily overridden for profile page styling.
911 call -> Dispatch unarmed City employee, typically a social worker, who specializes in the relevant situation, population or neighborhood.
Goal is to assist the individuals involved, to be compassionate instead of punitive, to get to the root cause of the issue.
There is still some kind of armed security backup for the social worker’s protection in situations that do escalate.
* It shows the top comment (It's a bad habit of mine - just reading the comments - so maybe I'll be more likely to click the story instead of the comments)
* Dark mode! Or light mode! Depending on your system settings.
* Easily switch between Top and New stories.
* No JS libraries! (Fast?)
If you’re on an iPhone iOS 13, add it to your home screen. It will open in its own window, not in Safari, so it will maintain scroll state. It also works as a Windows 10 app. Haven't tested on Android...
It's just a 24-hour project I wanted to do over break but I will likely keep it as my main reader, so I might add more features over time.
https://themeforest.net/category/static-site-generators https://themeforest.net/category/site-templates https://jekyllthemes.io/premium
Looking forward to your response!
But it does have the tone of a type of “data journalism” that we should see more often.
I would appreciate a site that treats all news the way 538 treats politics.
AKA instead of "Eval is Evil" we might instead say "XML is Evil"
* iPhone - iOS (touch only)
* iPad - iOS (touch only)
* iPad Pro - iOS "Plus" (iPad + attachable keyboard/trackpad)
* MacBook - iOS "Plus" (iPad + built-in keyboard/trackpad)
* MacBook Pro - macOS
* iMac - macOS
* Mac Pro - macOS