This is an interesting proposal for a declarative way of triggering permission dialogs, although it seems to overlap with the work being done on invokers (command and commandfor).
What really disgusts me is to see Google referring to this element as though it’s a done deal. It’s not. It’s a proposal …a proposal that Apple rejects and Mozilla rejects.
Words matter. Call your proposal a proposal, Google.
Update: They fixed it!
dialog, details, datalist, progress, optgroup, and more:
If this article helps just a single developer avoid an unnecessary Javascript dependency, I’ll be happy. Native HTML can handle plenty of features that people typically jump straight to JS for (or otherwise over-complicate).
The web is open, apps are closed. The majority of web users have installed an ad blocker (which is also a privacy blocker). But no one installs an ad blocker for an app, because it’s a felony to distribute that tool, because you have to reverse-engineer the app to make it. An app is just a website wrapped in enough IP so that the company that made it can send you to prison if you dare to modify it so that it serves your interests rather than theirs.
It’s great to see the evolution of HTML happening in response to real use-cases—the turbo-charging of the select element just gets better and better!
When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).
Hell, yeah!
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.
Hell, yeeeeaaaaahhh!!!
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
It’s pretty easy to write bad HTML, because for most developers there are no consequences. If you write some bad Javascript, your application will probably crash and you or your users will get a horrible error message. It’s like a flashing light above your head telling the world you’ve done something bad. At the very least you’ll feel like a prize chump. HTML fails silently. Write bad HTML and maybe it means someone who doesn’t browse the web in exactly the same way as you do doesn’t get access to the information they need. But maybe you still get your pay rise and bonus.
So it’s frustrating to see the importance of learning HTML dismissed time and time again.
Garrett talks through some handy HTML attributes: spellcheck, autofocus, autocapitalize, autocomplete, and autocorrect:
While they feel like small details, when we set these attributes on inputs, we streamline things for visitors while also guiding the browser on when it should just get out of the way.
Another handy accessibility testing tool that can be used as a bookmarklet.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
The EU is not the FCC. I wish every American tech pundit would read and digest this explainer before writing their thinkpieces.
It’s very common for US punditry to completely misunderstand the EU and analyse it as if it were a US political entity – imagining that its actions are driven by the same political and social dynamics as a protectionist industry within the US.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
Scott has written a perfect description of HTML web components:
They are custom elements that
- are not empty, and instead contain functional HTML from the start,
- receive some amount of progressive enhancement using the Web Components JavaScript lifecycle, and
- do not rely on that JavaScript to run for their basic content or functionality.
It’s so nice to see when someone else finds Huffduffer to be useful!
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
Here’s a good walkthrough of adding microformats to your site, starting with h-card and moving on to h-entry.
I didn’t want to play the game of striving to be seen.
I just wanted to be.
This is an interesting idea from Scott—a templating language that doesn’t just replace variables with values, but keeps the original variable names in there too.
Not sure how I feel about using data- attributes for this though; as far as I know, they’re intended to be site-specific, not for cross-site solutions like this.
Huh! I did not know this. Good to know!
This is a really interesting proposal, and I have thoughts.
Remember when I wrote about sizes="auto"? Well, it’s coming to Chrome! Hallelujah!