A few HTML tips
hacks.mozilla.org
hacks.mozilla.org
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?
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.
Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
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.
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
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
No news from Safari.
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.
And this is not even related to accessibility.
Of course, IE8 is dead, so I can't think of a reason to stick with them.
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.
Are you aware that we're completely able to read documents from thousands of years ago? C.f. Caesar's Bellum Gallicum, which is about 2,050 years old.
As to why you wrote it — heh, we've all been there.
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.
> 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).
https://stallman.org/stallman-computing.html
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.
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.
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.
fill: currentColor;
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'.
<i class="fa fa-pizza" aria-hidden="true"></i> <img src="pizza.png" alt="" />I do wish they didn't overwrite the traditional <i> tag, but I guess we're supposed to be using <em> for semantic HTML.
So … it can be made to work with a single request then.
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.
"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.
[0] https://html.spec.whatwg.org/multipage/semantics.html#the-i-...
<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.
You have the same resources and APIs (can you call HTML attributes an 'API'?) available to make the usage of icon fonts friendly for screen readers.
<i class="fa fa-globe" aria-label="Picture of a globe"></i>
<img svg="globe.svg" alt="Picture of a globe">
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?
[edit: formatting]
I use <span> on all of my projects.
SVG works for me with JS disabled (using Firefox on OS-X). Do you have any pointers on when/why SVG wouldn't work without JS?
I can only hope that his is mostly ignorance.
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").
Is that not typical?
(That said, if you're using webfonts for icons you should be using the unicode Private Use Area.)
An SVG is scalable, cacheable and can contain any vector art you could wish for. And it doesn't use characters to represent images.
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.
But fonts have hinting, so they look nice at low sizes and low resolutions. This is something that SVG is still missing.
Was their font just poorly designed?
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.
Why, then, does one see all sorts of strange characters on web pages which use icon fonts?
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.
Skype Web puts a whole <form> in a <label>, I guess it is for that reason
This matters more for touch screens, but I suspect most of the web is accessed at least sometimes through touch screens.
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.
Edit, to add: To avoid nesting you can use the for attribute. More info on the following link addressing checkboxes and input nesting, in general:
<label for="coolInput">Click me:</label>
<input type="checkbox" id="coolInput" />
w3.org: The label element may contain at most one descendant input element, button element, select element, or textarea element.
You just have to be a bit careful with it concerning screen readers.
EDIT: besides, there are CSS reasons for wrapping the input with a label.
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.
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/ .
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.
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.
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.
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.
See https://www.nngroup.com/articles/form-design-placeholders/
[1] https://www.nngroup.com/articles/form-design-placeholders/
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.
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)
Placeholders don't disappear if you just focus input, only when you type first character.
https://www.w3.org/TR/html5/forms.html#the-placeholder-attri...
> "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"
IE's been as up-to-date as any other browser for like 5-6 years now. Let the hate go already.
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]
[0] https://html.spec.whatwg.org/multipage/forms.html#attr-input...
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.
Probably the most common issue is to use green and red colors for some kind of status without also using text and/or symbols.
Do this: Remove all the placeholders. Now ask someone else to fill in the form. If they don't know what to do you need labels, not placeholders.
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?
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.
As always, do what's right for your (human) users, and you will eventually get the SEO benefit.
> 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).
<a class="fb sprite" href="..."> </a>
.sprite {
background-image: url("/sprites.png");
background-repeat: no-repeat;
}
.sprite.fb {
background-position: -4px, -4px;
width: 42px;
height: 42px;
}
.sprite.fb:hover {
background-position: -4px, -54px;
}
I don't exactly like it but haven't come across a better solution.
> Couldn’t be much more from the hearth<br>
Couldn’t be much more from the heart.
#whatever-container p:first-of-type { margin-top: 0; }
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.
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?
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>.