Using the HTML field is normally a good idea when you're asking the user to enter a URL. It doesn't make a huge difference on desktop browsers, but makes it a lot easier on mobile browsers. On iOS, when you've focused on a URL input field, the keyboard switches to a slightly diffe...
Browser support tables for modern web technologies
In August 2012, I wrote a quick script to stream front-page Hackernews stories to an IRC channel on Freenode (##hackernews in case you're interested) so that I could quickly glance at popular stories there instead of needing to load Hackernews. Since IRC is my feed reader, I've always tried to pipe as much there as possible.
My favorite part here:
So in 2.5 years of parsing the HTML, I never had any problems. In 2 days of parsing the JSON API, I hit a glitch where all the stories were empty.
Since more people and programs see the HTML than use the API, the HTML ends up being more reliable.
While I occasionally do some small uploading tweaks like this, it seems like ages since I created webpages like this outside of more elaborate content management systems. Hooray for raw HTML and CSS! It’s also a bit refreshing to do it all manually in an interface instead of via FTP or other means.
Responsive HTML5 and CSS3 site templates designed by @ajlkn and released under the Creative Commons license.
I thought it was a pretty slick use of HTML to create some really simple and broadly useful UI.
Then earlier today I noticed that Jeremy Keith has recently switched to using this on his personal site in the comments section to provide toggles for his various webmention types including shares, likes, bookmarks, etc. But this is where I’m noticing a quirky UI issue that isn’t as web friendly as it could be. Jeremy and others (including myself own my own site) will often provide ID tags so that one can give permalinks to the individual comments using fragments of the form:
But here’s where the UI problem lies. The first fragment URL only resolves to the page instead of the specific bookmark hiding behind a <details> tag whereas the second fragment URL resolves to the page and automatically scrolls down to a comment by DominoPivot. It does this in both Chrome and FireFox and I would presume operates similarly in other browsers.
I suspect that most users would expect/prefer that the fragment URL should automatically expand the <details> tag and scroll down the page to that ID or fragment as well.
Perhaps Jamie, Jeremy, Tantek, Kevin or others may have some trickery to make this happen? Otherwise, do we need to start digging into specs and browsers to get them to better support this sort of fragment related functionality? Perhaps it’s this section of the HTML spec, the URL of which has such a fragment and therefor scrolls down properly if you click on it? (Meta pun intended.)
Today W3C and the WHATWG signed an agreement to collaborate on the development of a single version of the HTML and DOM specifications. The Memorandum of Understanding jointly published as the WHATWG/W3C Joint Working Mode gives the specifics of this collaboration. This is the...
Search the web for "CSS classes" and you'll find numerous well intentioned references which are imprecise at best, and misleading or incorrect at worst. There are no such things as "CSS classes". Here's why you should refer to HTML classes, CSS class selectors, or even CSS pseudo-classes, but not "C...
Some thoughts on entry points to web development today, and my fears about the loss of something that has enabled so many people without a traditional computer science background to be here.
While I want people that I mention in some of my posts to be aware that they’ve been mentioned by me, I don’t necessarily need to add to the visual cruft and clutter of the pages by intentionally calling out that link with the traditional color change and underline that
<a> links in HTML often have. After all, I’m linking to them to send a notification to them, not necessarily to highlight them to everyone else. In some sense, I’m doing this because I’ve never quite liked that Twitter uses @names highlighted within posts. All the additional cruft in Twitter like the “@” and “#” prefixes, while adding useful functionality, have always dramatically decreased the readability and enjoyment of their interface for me. So why not just get rid of them?! I’m glad to have this power and ability to do so on my own website and hope others appreciate it.
In the past I’ve tried “blind notifying” (or bcc’ing via Webmention) people by adding invisible or hidden links in the page, but this has been confusing to some. This is why one of the general principles of the IndieWeb is to
Use & publish visible data for humans first, machines second.
Thus, I’ve added a tiny bit of CSS to those notification links so that they appear just like the rest of the text on the site. The notifications via Webmention will still work, and those who are mentioned will be able to see their names appear within the post.
For those interested, I’ve left in some hover UI so if you hover your mouse over these “hidden” links, they will still indicate there’s a link there and it will work as expected.
As an example of the functionality here within this particular post, I’ve hidden the link on the words “mentioning” and “person-tagging” in the first paragraph. Loqi, the IndieWeb chat bot, should pick up the mention of those wiki pages via WebSub and syndicate my post into the IndieWeb meta chat room, and those interested in the ideas can still hover over the word and click on it for more details. In practice, I’ll typically be doing this for less relevant links as well as for tagging other people solely to send them notifications.
I’m curious if there are any edge cases or ideas I’m missing in this sort of user interface? Sadly it won’t work in most feed readers, but perhaps there’s a standardizable way of indicating this? If you have ideas about improved presentation for this sort of functionality, I’d be thrilled to hear them in the comments below.
There are a lot of reasons to love WordPress, but one of the reasons I keep WordPressing is the supportive community. While I have no formal training as a web developer, I don’t like describing myself as “self-taught.” I didn’t figure this out on my own, I was taught by a supportive communit...
It began, as many things do, with a silly conversation. In this case, I was talking with our Front End Technology Competency Director (aka "boss man")
By choosing images over links, and by restricting markup, Facebook, Twitter and Google+ are hostile to HTML. This is leading to the plague of infographics crowding out text, and of video used to convey minimal information. The rise of so-called infographics has been out of control this year, though the term was unknown a couple of years ago. I attribute this to the favourable presentation that image links get within Facebook, followed by Twitter and Google plus, and of course though other referral sites like Reddit. By showing a preview of the image, the item is given extra weight over a textual link; indeed even for a url link, Facebook and G+ will show an image preview by default.