All of the other cool new input types appear to be on the way in the modern browsers (http://caniuse.com/#search=input%20type), but Safari and Firefox don't appear to be budging at all.
I would prefer to use the native date pickers across devices, but I feel like I have been waiting on those elements to land for years now. Did I miss something?
A few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't guarantee browser consistency across their offices, and of course mobile was a concern as well.
I don't remember the details and wish I'd written it up, but the inconsistencies across browsers about required values, bounds - not to mention trying to do "trivial" things invalidating Saturdays and Sundays - were astounding.
datetime-local helped a bit, but wasn't fully supported in IE. I spent 4 days working on that, then spent an hour ripping my code apart and adding moment.js and the jQuery UI Datepicker widget. At least it worked.
+1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.
I'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern.
Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React.
My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation.
Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.
I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component.
I also have this ugly mess of scss that don't live with the components.
What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization.
I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.
Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here.
Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world.
But you have to do things like prefixing to make sure your css
Seems that Firefox are planning to support it. Latest discussion on Bugzilla was in May of this year (https://bugzilla.mozilla.org/show_bug.cgi?id=888320) where they were discussing implementation details.
They're available on mobile Firefox and Safari (well partially on the latter) but not the desktop versions. I wonder if it's because they're not implemented at the OS level?
I don't mind website designers defining what fonts to use. That choice is almost always something I don't want, unless it's serif or sans-serif. I can override that choice with my own, which is better for me. Having the same font on every website increases readability and pleasure of using the web. Browsers allow for this in the user visible configuration, perhaps for this reason.
Also, security. I don't trust random fonts from the internet, to not be malicious, so I disable them all.
If I choose readability and security, use a normal browser feature to do this, by disabling website enforced font choice, the website should not break.
Icon fonts are definitely a hack. There's no fallback to anything sensible when the font can't be used. It just breaks, and the website is unusable. At least use a title attribute, so that when hovering over some random character I can see what the supposed icon I never saw stands for. Especially when used for icon only navigational controls.
Perhaps designers assume that they are in full control of their website appearance, and don't include into consideration user's choices, enabled by various browser options/configurations.
Web Fonts for images are a true anti-pattern. It's actually almost funny how many pages are full of ſ and so forth, because they assume that folks are using a graphical browser running JavaScript.
I don't think there's anything wrong with assuming people are running a graphical browser.
We're at the point where, depending on your exact industry/usecase, earlier IE versions are less than 1% for a lot of 'mainstream' sites. The amount of people who aren't able to render a custom web font, let alone a non-graphical browser, would be in the extreme minority.
IMHO, that is not a use case that's not worth worrying about.
Well, of course there are those who are weird, like Mr. Stallman:
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special
relationship with. I usually fetch web pages from other
sites by sending mail to a program (see git://git.gnu.org
/womb/hacks.git) that fetches them, much like wget, and
then mails them back to me. Then I look at them using a
web browser, unless it is easy to see the text in the
HTML page directly. I usually try lynx first, then a
graphical browser if the page needs it (using konqueror,
which won't fetch from other sites in such a situation).
But there are other groups of people for which this is relevant: Blind or otherwise visually impaired people depending on screen readers or similar. Those don't have a good choice and abusing text there makes the experience unbearable.
I received an accessibility report for a website made by a big reputable accessibility agency, and they had no problem with us using Font Awesome. It's ignored by screen readers, unless you put a title attribute, which you can do if the icon is more than decorative.
That said, I use NoScript with 'Forbid Font-Face' enabled, so a lot of the time I see squiggles instead of icons. But that's my choice, and I'm almost certainly in the minority, so I'm not angry about sites that use fonts instead. SVG probably will come to replace font icons, but for now, they've been really helpful for a lot of small sites.
Stallman isn't a group of people though, he's one very very extreme case that frankly doesn't matter in the big picture of web accessibility and it probably isn't going to hurt anyone if he can't see every bit of your site as perfectly as everyone else.
Most icon fonts use PUA codepoints to avoid issues with screen readers. If you're not going to use icon fonts, what are you going to use? Images? CSS Backgrounds? Inline SVGs?
Screen readers can't read any of them. Thankfully there are ways to make all of these accessible, with things like ARIA attributes.
While that is probably 'better' how in practice does it matter. SVG (esp with sprints) vs icon font are basically the same. Both are ways of embedding multiple vector images in one resource that you attribute meaning to using `title` attributes. In practice they will behave pretty much exactly the same.
There are still some issues with that – for example, it's easier to change attributes like text colour when using an icon font, something that becomes substantially more awkward with SVG. This is appropriate for things like buttons and other elements with hover effects.
Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.
> Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.
It's only correct to infer that web developers care less if the cost of supporting either is the same.
(Also many legally blind people use graphical browsers; legally blind is not the same as "unable to see anything").
I like the idea of making a commitment to accessibility, simplicity, and universality.
<svg> may not work for people like me who disable javascript. It introduces potential security issues (in my understanding). It's complex, meaning it's hard to guess how it will interact with tools that want to access the page (like for visually impaired or for other purposes).
I don't like these things, so I'll try to make a stand and not use it. Of course, I only have that luxury because I don't make websites for a living.
I looked into it further and I think I'm mostly wrong about <svg>. You can embed javascript into it, but if you don't, then as far as I can tell it works fine for me. Sorry!
That makes sense…and I think that's where the potential security vulnerability comes into play - if you allow untrusted users to upload SVGs, then they could potentially be uploading javascript to your site, offering a vector for XSS. As far as I can tell, adding your own SVGs to your site doesn't open up any novel security issues.
SVG is considered more accessible because it's an image, not text. 'f' doesn't mean aeroplane (even though it looks like an aeroplane in a 2010-style graphical font) but img alt="plane" does.
That's an argument for not using an icon font which remaps normal characters but the most common ones use private-use characters which are ignored by screen readers. In which case are these not equally accessible?
<i class="fa fa-globe" aria-label="Picture of a globe"></i>
<img svg="globe.svg" alt="Picture of a globe">
Accessibility is more about process and testing than any particular technology since they all can be done poorly.
Apologies if this is a massively ignorant question, but isn't the <i> tag an inline text span? In which case, isn't it wrong to have it be empty?
The i element represents a span of text offset from its
surrounding content without conveying any extra emphasis or
importance, and for which the conventional typographic
presentation is italic text; for example, a taxonomic
designation, a technical term, an idiomatic phrase from
another language, a thought, or a ship name.
Using it without text strikes me as a hack, and one that is hostile to usability, among other problems. I understand why it would work, but it's abusing the technology as far as I can tell.
Since I've seen this in at least two comments now, can somebody explain to me why it's not considered an anti-pattern in 2016?
I would agree with that – it's a convention which the FontAwesome project uses for reasons I haven't looked into (I'm assuming not wanting to type 6 more characters).
Your mailbox icon 'ſ' will be read aloud as 'latin small letter long s' or 'esss' if you're lucky.
But I can't really tell if you're actually saying that the ability for web pages to be read aloud coherently is 'a use case that's not worth worrying about'.
This is a good point. There is additionally ligatures used by the Google material icons. These let you put an actual textual representation of the icon and only replace it with an icon if the browser supports it: http://google.github.io/material-design-icons/
The <i> tag in modern HTML does not mean "italics", though the examples given to illustrate its new semantics are all things conventionally set in italics.
"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts." [0]
Its use for text-as-icon is arguably, despite obviously not being a use classically set in italics, within the defined semantics of the <i> tag.
EDIT: Though FAs use isn't actually text-as-icon, it uses empty tag as an icon. That's not consistent with the semantics of the tag.
In earlier versions of the HTML specification, the <i> tag was merely a presentational element used to display text in italics, much like the <b> tag was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance.
Except that would require multiple web requests unless you were using an image sprite. Font Awesome and Glyphicons solve this by using a font file or sprite.
I do wish they didn't overwrite the traditional <i> tag, but I guess we're supposed to be using <em> for semantic HTML.
Hear, hear. Web fonts are fine when used as fonts. They are not fine when used as images (unless the image corresponds to an actual Unicode character).
From a design perspective font icons are a very good solution when compared to sprite sheets or SVG. They are scalable, they load a single time, and contain nearly every iconic type of symbol you could want in a UI. That's not an anti-pattern.
Emoji are almost exclusively used embedded in regular text. Emoji work similar to our regular alphabet, only that they are typically used to express emotions and abstract concepts that are harder to express in regular words. Since we have regular text and emojis used in the same context (and often as part of the same sentence) it makes sense for unicode to support both.
This is fundamentally different from icon fonts. twitter icon or mailbox icon are not meant to be used inside of text, so they have no business in fonts.
Web Fonts abuse HTML: they take text and give it a different meaning. The letter 'a' does not indicate a daisy with pink petals; it is the letter 'a,' the English word 'a' and so forth.
Think for a moment about what Web Font users do: sprinkle garbage throughout their pages; run JavaScript to dynamically load stuff (and possible destroy the privacy and/or security of the client); dynamically update the page — all when a simple, semantic image could have done the trick.
It's kinda insane, like rendering a page by loading JavaScript to slowly append characters to the DOM.
That's just inaccurate – AFAIK all modern icon fonts make use of the Unicode PUA, which is specifically intended for this sort of application. The characters used have no semantic meaning beyond what the application, including its fonts, intend.
Some day we should deprecate browsing the web with HTML 1.0 tools, apart from web crawlers who know what they are doing. Sticking with that is akin to sticking to horses on the road: It has its advantages, but you can require everyone to build horse-friendly roads for you in 2016. At least horse riders aren't vocal about their bad experience.
In entire fairness, the evolution of language may well make this impossible, or nearly so, regardless of how you structure your content. It's not unreasonable to shoot for 100 years, though.
Anyone remembers Dan Cederholm (http://www.simplebits.com/) and his excellent books "Web Standards Solutions" and "Bulletproof Web Design"? He even had a series of exercises like this on his blog.
Oh, the gone days of the web which was a web and not some misfit wannabe app engine :(
Speaking as someone partially responsible for turning the web into "some misfit wannabe app engine :(", yes – those were some of my favorite books when they were released.
To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label? He's saying make everything semantic, and then semantically breaking forms.
Also if you have any inputs that don't have a label for whatever reason you either have to wrap them in them any way to get CSS to work or make sure you never rely on the input being nested in the label in your CSS.
And having them apart also makes it easier to design responsively if you want a side-by-side design for desktop vs a stacked design for mobile.
Saves having to add a for tag I guess.
I guess a lot of that article is opinion though, so you're always going to get people objecting to one point or another, though a lot of it seems sensible advice.
I don't think the article is even advocating for nested vs. not-nested inputs with labels, the author just picked nested to use in the example. The point of the example was to have a <label>. There's no reason to go to war over nested vs. not-nested.
The only exceptions to "each input must have a label" are inputs of type "hidden" and ones that make button controls so the value attribute effectively labels the control.
But that means there may be an area between the label and the input element (depending on margins and so forth) which is not clickable. Having the label separate makes sense if it's all in a table-like structure, though.
> Is it common these days to nest inputs in labels?
Been developing websites for almost 15 years now, and I recall this always being a common thing to do.
> To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label?
I agree that it's conceptually broken, but it is not semantically broken -- since the HTML5 spec and screen readers all recognize this as an equally valid way to define a label on an input.
So they're both equally "correct", just a trade-off of ease-of-styling (for some designs) vs. saving a few bytes and mental overhead of assigning for/id attributes to them.
I would call it pragmatic, as it makes the CSS easier when you want to put a custom checkbox design. Either way, it doesn't seem to be doing them any harm.
I'd thought that was the only way to get clicking on a checkbox label to trigger the checkbox click (unlike other inputs where you could simply use a for label).
I can see the value of almost all of those recommendations but I don't understand the value of using the correct header sequence or tagging subheaders. I don't see anything in the linked W3C article that explains why I should use one idiom over another.
Consider automated TOC generation. If you use the h* tags as they're designed to be used, it's trivial to produce a table of contents for even a very complex document by simply extracting and numbering the headers, and hyperlinking it is almost as easy.
Consider screen readers and other accessibility technologies. If you use the h* tags as they're designed to be used, it is very easy for someone who cannot see your document to navigate within it by moving from header to header, and to navigate within sections by moving from subheader to subheader.
These are two examples of automatically extracting semantic information from an HTML document in order to enable new ways of interacting with its content. Such methods can only work if the semantic information is there to begin with. Using standard header tags in the standard fashion is a good, simple way to include such information. It is not the only way, but it is by far the most widely understood way, and you do both yourself and your readers a favor by not requiring the use of special-case exceptions to parse your content.
Of course, if your purpose is not to publish content, then this may not be a major concern for you. Perhaps you're building one of those modern-style marketing sites where the presentation is excruciatingly visual, the standard interaction methods are unnecessarily hijacked, and the content is minimally existent. In that case, I wouldn't worry so hard about it. But if you're publishing something that's got some meat to it, this is a standard worth following.
Also, WRT screen reader users, like sighted users, they often scan the document by skimming the headings, links, etc. Screen reading software will pull these out into separately scannable lists available for the user to skim through outside of the context of the surrounding content. Having out of order heading creates a document outline that is confusing. This is why it's also important to write good linked text as scanning 20 links that all say "read more" is useless.
A lot of it is semantics. A bunch of HTML5 is semantic vs. actually having different behavior. <header> behaves no differently than <div id="header"> but is more semantically correct.
A simpler way to say "more semantically correct" is "correct." Please don't trivialize the importance of semantics. Proper semantic representation makes documents more accessible.
I don't find the header, article, section, etc tags to be sufficiently clear that they are always used in the same way by different people. But maybe I'm missing something -- how do they improve accessibility?
Take a look at http://accessiblehtmlheadings.com/ for a pretty solid introduction. The tl;dr: is that, used properly, they enable screen readers and similar to identify document structure and make it more easily navigable.
For a considerably more detailed treatment with special attention to concerns around accessibility and some information on other document elements with similar significance, take a look at http://accessiblehtmlheadings.com/ .
It's helpful to other computers reading your website. This can be anything from a screen reader to a search engine crawler to a script like Readability for extracting the readable sections of a website to a document.
A note regarding alt attributes on img: they should almost always be empty. Please don't just fill it with the related title or heading, as it just creates a lot of unnecessary text for screen readers. More: http://www.456bereastreet.com/archive/200811/writing_good_al...
Funny how they answered a question about paragraph tags that I was wondering yesterday. Most answers to the "p vs br" question seem to be "do whatever you want", but the recommendation in the article seems most correct to me, since p tags are for the parser(in case it needs to know what the paragraphs of the body content are) while breaks are presentational.
I think the bigger concern is that br tags don't fit the general box model. You can have CSS like p {margin-top: 2em}, but br is more like a newline, tied to the text flow itself. Which, as noted in the article, is okay if you are trying to just affect text flow, as in a poem with explicit line breaks.
But actually trying to understand "what is a paragraph" using the semantic markup is probably a fool's game. What IS a paragraph anyway? There's not many automated tools that could make any use of that very semantic definition.
Screen-readers can iterate and skip paragraphs. If you have an article and you group your sentences in paragraphs, the document is easier to navigate. Paragraphs would also be helpful if you wanted to write a script to export an HTML document to LaTex/Word/ect as those will automatically indent paragraphs for you.
I'm curious if you should use p at all. Unlike most other tags p doesn't not enclose block elements. So easy to break. Soooo many bugs related to starting with a paragraph, embedding something inside it, not realizing the content past whatever was embedded is no longer in any paragraph
Paragraph is an atomic entity (irl), not a block of things. Inserting elements into paragraph is like inserting into an image; nonsense in many cases. If you want to apply css to some paragraphs, just put some divs/spans in there.
Can anybody tell me how legit the placeholders recommendation is? I understand it's not accessible, but on a limited viewport, having the text tell the user what you want seems like a no-brainer. And I see it a lot. Isn't there some other way to provide accessibility?
The recommendation is totally legit, even ignoring accessibility concerns (which are true). I can't tell you how many times I've tabbed onto the next field and had to tab off just to see the value I was supposed to be putting in. It gets worse when this is in JS and for whatever reason, the field name doesn't reappear, or better yet, when the suggestion doesn't disappear and I have to manually erase it.
It gets even more confusing when there is a suggested format, like date, you have to manually enter. Was it mm/dd/yy or mm/dd/yyyy? All of that should be above the form input.
Using nothing but place holders is a serious pet peeve of mine on all levels. Please don't, just don't do it. I don't understand what benefit is has. I suppose it works fine if you have users that only use mouse clicks, but it is mayhem for people who use key commands.
> "User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and the control is not focused"
Yes, I am now saying the behavior is wrong and goes against user experience. Since IE is going by specifications then I agree my dislike for it in this instance is likely misdirected. On the other hand, it seems the other browsers saw the spec and rightfully disagreed with this behavior; so I'm back to disliking IE.
> On the other hand, it seems the other browsers saw the spec and rightfully disagreed with this behavior
The w3 spec almost certainly postdates the browser vendors decision on what they would implement (and probably the actual implementation -- all the meaningful work on HTML goes on in the WHATWG living standard, the W3 spec is a frozen backward-looking interpretation of that, but even the WHATWG spec is probably a result of the vendor's decision on what to implement, rather than the decisions being based on the spec.) It probably says what it says precisely because that is the level of commonality of behavior between major vendors, with non-Microsoft vendors also displaying the placeholder when the field is empty but focused.
EDIT: Note also that the WHATWG spec, at least, specifies additional behavior if the user agent does not normally display the value when focused ("If a user agent normally doesn't show this hint to the user when the control is focused, then the user agent should nonetheless show the hint for the control if it was focused as a result of the autofocus attribute, since in that case the user will not have had an opportunity to examine the control before focusing it.") [0]
Wouldn't the type attribute on the input indicate to the phone/browser/etc what's to be expected? Perhaps with a title attribute added?
I'm okay with it, and I'll do it from now on. Just seems kinda weird to start displaying things based on accessibility. I thought that all played out behind the scenes (in things like the alt attr for images)
That said, designers often dislike labels. Float labels are about the best compromise I've seen - https://css-tricks.com/float-labels-css/. You can see them in action on Digital Ocean.
Accessibility is not just about screen readers. Consider, just as an example, color blindness. Choosing the right set of colors to make your site accessible to color blind people is hugely important but it will definitely change the look of your site.
Probably the most common issue is to use green and red colors for some kind of status without also using text and/or symbols.
Yes, I agree completely. Other groups include those with learning difficulties, restricted motor skills and partial-sight. It's a big issue to fit into a small HN comment.
It's useful from a minimal design perspective but I've started to avoid using placeholders after seeing this article[1], instead trying to put the field name, example text or caption, etc outside the input.
it's not just accessibility it's also keeping the form usable.
As the placeholder text goes when you type in the input you loose the reference to that input, so the only way to check if you're typing in the right box is to clear the input.
How limited is your viewport? I still have an old HTC Incredible 2 at home that I use for testing. Though not the smallest, it's only 320x533 (portrait). I'm used to a much larger viewport, and viewing forms with those dimensions are fine. Just ensure that your form fields aren't microscopic. Using the placeholder for explanation also removes the explanations when focusing on the field. A label is permanent.
I think it can definitely be a challenge sometimes: go to youtube.com and look at their search input (says "Search" in a placeholder). There's no way they can put the label above the search box, it would almost double the size of their header. So they'd have to put the Search label to the left or something.
Search boxes are a special case. There is one input and the form submit button is usually adjacent to the input and clearly marked with a search glyph or the word search. One a search form has multiple fields it tends to use the labels e.g. google's advanced search forms.
Question: Can anyone comment on how important HTML taxonomy in terms of SEO (disregarding accessibility). Will the use of <header> and <article> make any difference in how a page is indexed and ranked directly or indirectly?
One indirect way I can see SEO benefiting is via sharing. Facebook crawling will have an easy time grabbing the <h1>Title</h1> along with whatever comes first in <p>for an excerpt</p>.
Is there any no-brainer reasons or supporting evidence proper taxonomy helps rankings?
I have seen no evidence to suggest that search engines care about HTML5 semantic tags. While the tags may be one particular signal, their algorithms use a lot of signals, so don't rely on markup alone. I suspect if they did give them any value, they would quickly be abused by the black-hats, so they don't bother.
As always, do what's right for your (human) users, and you will eventually get the SEO benefit.
Agree with your overall sentiment, but should clarify this:
> I have seen no evidence to suggest that search engines care about HTML5 semantic tags
I think you mean "HTML5 sectioning elements" (header, footer, section, article, aside, main). Because search engines absolutely positively do care about proper "semantic" use of other tags (especially h1...h6).
Don't disregard accessibility. Think of the search engine crawler as a disabled user. The ARIA roles (and many HTML elements have good, sensible defaults) carry a lot of information that a search engine can use as easily as a screen reader can. Good a11y is good SEO.
Thing is that wcag recommends following defined web standards, but no screen reader I tried could handle html5 style of relative h-tags, like multiple h1 tags. So if you want to adher to wcag rules, and support screen reader, you need to stick to html4. This will probably change, but in order for us to support screen readers, we ended up with some badly written html5.
As for SEO, my experience is that the big crawlers handle html5 better than screen readers, and that atleast Google puts more emphasis on font size as a measure for the pages h1. "If it looks like the pages heading, people will see it as the h1, so we should consider this a better cue than tags the users don't see" sort of logic.
Outlines are still broken in browsers, yes (so multiple nested-level <h1>s ain't gonna work in <main>), but things like the banner and nav roles work just fine and come free with the appropriate tags.
I wonder if Google should put some time/effort into making a better (ideally free to use) screen reader? They seem to have pretty advanced technology for finding the human-relevant parts of a web page.
The first no-brainer that springs to mind is <nav> so that search engines can tell words related to the current page apart from words related to pages you might navigate to.
I'm curious if there is any good solution to use sprite sheets with background-image, possibly with a hover effect, and still get the accessibility benefits of alt tags? For instance:
What would you do to make that accessible? I did some Googling about this a few weeks ago, and it seemed to be a topic of "ongoing research." None of the solutions I could find were very appealing. So, any suggestions?
Not the best solution - but the solution I've used in the past: `<a href="/" target="_blank" title="Facebook"><img class="sprite fb" src="/images/spacer.gif" alt="Text" background-image:url('/images/sprites.png')></a>`
I don't exactly like it but haven't come across a better solution.
That feeling when the first paragraph of an article points out something you've been doing wrong all along :D. I use <br> in between paragraphs and it looks horrible, what should I be using instead?
> There are some CSS limitations though: when using SVG this way, with <use> linking to a <symbol>, the image gets injected in Shadow DOM and we lose some CSS capabilities.
Which is why SVG "symbol" and "use" are best avoided. Your client will inevitably ask you to style an icon and you won't be able to. Avoid the shadow DOM and you'll have full CSS capabilities.
> Your client will inevitably ask you to style an icon and you won't be able to.
It's not that you can't style it, it's that you can only style _the entire image_. Which means it's a perfectly good replacement for icon fonts since "styling" an icon font is limited to changing the size and color. You can do that and more with an SVG included via <use>.
At worst, SVG is as styleable as any graphic or font, at best much more so.
You shouldn't use SVG for things with first-class support in HTML, sure, but for anything else it is a good solution, afaict. Can you give a counter-example?
Me too. I've been doing web dev for 10+ years and I've never wrapped an input in a label tag. Always used the for attribute. Didn't even cross my mind it could be done differently.
We've banned this account for repeatedly posting uncivil and unsubstantive comments to HN. If you don't want it to be banned, you're welcome to email hn@ycombinator.com. We unban accounts when people give us reason to believe they'll follow the rules in the future.
http://caniuse.com/#search=Date%20and%20time%20input%20types
All of the other cool new input types appear to be on the way in the modern browsers (http://caniuse.com/#search=input%20type), but Safari and Firefox don't appear to be budging at all.
I would prefer to use the native date pickers across devices, but I feel like I have been waiting on those elements to land for years now. Did I miss something?