-
Notifications
You must be signed in to change notification settings - Fork 4
/
atom.xml
459 lines (298 loc) · 21 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[Category: HTML | TJ VanToll]]></title>
<link href="http://tjvantoll.com/blog/categories/html/atom.xml" rel="self"/>
<link href="http://tjvantoll.com/"/>
<updated>2013-01-24T22:06:33-05:00</updated>
<id>http://tjvantoll.com/</id>
<author>
<name><![CDATA[TJ VanToll]]></name>
<email><![CDATA[tj.vantoll@gmail.com]]></email>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[Using the body Element as a Top Level Container - Is it Safe Yet?]]></title>
<link href="http://tjvantoll.com/2013/01/05/is-it-safe-to-use-the-body-as-a-top-level-container-yet/"/>
<updated>2013-01-05T14:21:00-05:00</updated>
<id>http://tjvantoll.com/2013/01/05/is-it-safe-to-use-the-body-as-a-top-level-container-yet</id>
<content type="html"><![CDATA[<p>View source on almost any web page and you'll likely see the following:</p>
<p>``` html Common HTML Template
<html></p>
<pre><code><head></head>
<body>
<div id="wrapper">
<!-- All the things -->
</div>
</body>
</code></pre>
<p></html>
```</p>
<p>The use of a wrapper or container <code>div</code> around the page is fairly universal. It is commonly used to perform tasks such as centering a page's content or providing a shadow or border to frame it. But, since the <code>body</code> element is a necessity in the markup, why can't it be styled directly instead? Why is a wrapper <code>div</code> used?</p>
<p>Historically there have been a number of issues with using the <code>body</code> element as a top level container in old versions of Internet Explorers. If you're supporting IE >= 8 you're good, but there are some things <a href="#now">you should be aware of</a>.</p>
<!--more-->
<h3>IE 5.5</h3>
<p>To get to the origins of the wrapper <code>div</code> let's go way back. A pretty common practice is to center the top level container using <code>margin: 0 auto</code>, and this works fine in all browsers... back to IE 5.5. IE 5.5 did not support <code>auto</code> margins so this approach did not work.</p>
<p>To center the top level container in IE 5.5 you had to make use of <code>text-align: center</code> as such:</p>
<p>``` css Centering the top level container in IE 5.5
body {</p>
<pre><code>text-align: center;
</code></pre>
<p>}</p>
<h1>wrapper {</h1>
<pre><code>width: 1000px;
text-align: left; /* counteract the declaration on body */
</code></pre>
<p>}
```</p>
<p><code>text-align: center</code> <em>should</em> only affect inline elements, but IE 5.5 incorrectly applied it to block elements as well. (Note: The <code>text-align: center</code> bug was fixed in IE6 standards mode, but the behavior remained in Internet Explorer's quirks mode to this day.)</p>
<h3>IE6</h3>
<p>IE6 implemented <code>auto</code> margins, so <code>margin: 0 auto</code> was now safe to use on the <code>body</code>. Additionally, IE6 fully supports adding a <code>width</code>, <code>padding</code>, <code>margin</code>, and <code>border</code> to the body element. Take the following CSS:</p>
<p>``` css
body{</p>
<pre><code>width: 90%;
border: 2px solid red;
background-color: black;
color: white;
padding: 10px;
margin: 0 auto;
</code></pre>
<p>}
```</p>
<p>The layout renders the same in IE6 as it does in the latest version of Chrome (23 as of this writing).</p>
<div style="overflow: hidden;">
<div style="float: left; width: 49%;">
<h4>IE6</h4>
<img title="Styling the body element in IE6" src="http://tjvantoll.com/images/posts/2013-01-05/IE6.png">
</div>
<div style="float: right; width: 49%;">
<h4>Chrome</h4>
<img title="Styling the body element in Chrome" src="http://tjvantoll.com/images/posts/2013-01-05/Chrome.png">
</div>
</div>
<p>Believe it or not using the <code>body</code> element as a top level container is actually safe in IE6.</p>
<p><a name="zoom"></a></p>
<h3>IE7</h3>
<p>If there are no issues with IE6 why am I still writing? IE7 introduced a feature new to Internet Explorer, zoom, and with it came a new bug.</p>
<p>When a <code>margin</code> or <code>width</code> is applied to the <code>body</code> and the user zooms, IE7 incorrectly treats the left edge of the <code>body</code> as the edge of the viewport. This shift bumps content on the right hand side of the page outside of the screen. The image below shows the result of a zoomed in window and styled <code>body</code> in IE7.</p>
<p><img src="http://tjvantoll.com/images/posts/2013-01-05/IE7Zoom.png" title="Zooming in IE7" style="max-height: 400px;"></p>
<p>This issue is not present using a wrapper <code>div</code>.</p>
<h3>Beyond IE7</h3>
<p>In my testing beyond IE7 there are no major issues using the <code>body</code> element as a top level container. There are however a few things to be aware of.</p>
<p><a name="now"></a></p>
<h3>Positioning</h3>
<p>Any absolutely positioned elements will be positioned relative to the viewport rather than the newly placed <code>body</code>. To fix this set <code>position: relative</code> on the <code>body</code> as such:</p>
<p>``` css Positioning elements relative to the body rather than the viewport
body {</p>
<pre><code>margin: 0 auto;
width: 90%;
position: relative;
</code></pre>
<p>}
```</p>
<h3>Backgrounds</h3>
<p>Backgrounds applied to the <code>body</code> will take up whole page regardless of margins. Consider the following:</p>
<p>``` css
body {</p>
<pre><code>background: black;
margin: 0 auto;
width: 200px;
</code></pre>
<p>}
```</p>
<p>Here, the background of the entire viewport will be black rather than a centered 200px block.</p>
<p><img src="http://tjvantoll.com/images/posts/2013-01-05/background-before.png" title="background on a body element" style="max-height: 300px;"></p>
<p>Luckily, this can be worked around by applying a <code>background</code> on the <code>html</code> element.</p>
<p>``` css
html {</p>
<pre><code>background: white;
</code></pre>
<p>}
body {</p>
<pre><code>background: black;
margin: 0 auto;
width: 200px;
</code></pre>
<p>}
```</p>
<p>Which renders as expected:</p>
<p><img src="http://tjvantoll.com/images/posts/2013-01-05/background-after.png" title="background on a body element with background on html element" style="max-height: 300px;"></p>
<h3>scrollHeight and scrollWidth</h3>
<p>In WebKit based browsers the <code>body</code>'s <a href="https://developer.mozilla.org/en-US/docs/DOM/element.scrollHeight">scrollHeight</a> and <a href="https://developer.mozilla.org/en-US/docs/DOM/element.scrollWidth">scrollWidth</a> properties are unaffected by declared <code>height</code> and <code>width</code> styles. For example:</p>
<p>``` html scrollHeight and scrollWidth on the body element
<html></p>
<pre><code><head></head>
<body style="height: 200px; width: 200px;">
<script>
console.log(document.body.scrollHeight);
console.log(document.body.scrollWidth);
</script>
</body>
</code></pre>
<p></html>
```</p>
<p>This will log <code>200</code> for both in all modern browsers with the exception of WebKit based ones. WebKit will return the height and width of the viewport.</p>
<p>While you are unlikely to run into this directly, you may use a library that does. For example, this <a href="http://bugs.jqueryui.com/ticket/8940">causes an issue</a> trying to constrain <a href="http://jqueryui.com/draggable/">jQuery UI draggables</a> within the <code>body</code>.</p>
<h3>Is it Safe to Use Yet?</h3>
<p>The <a href="#zoom">zoom issue in IE7</a> is bad, but if you're no longer supporting IE7 it's safe to drop the wrapper <code>div</code> and style the <code>body</code> directly.</p>
<p>That being said, there's no harm in leaving a wrapper <code>div</code> in place. So if you have any doubt stick with <code><div id="wrapper"></div></code>.</p>
<p>Know of any other bugs with styling the <code>body</code> element? Let me know in the comments.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[The Enter Key should Submit Forms, Stop Suppressing it]]></title>
<link href="http://tjvantoll.com/2013/01/01/enter-should-submit-forms-stop-messing-with-that/"/>
<updated>2013-01-01T15:54:00-05:00</updated>
<id>http://tjvantoll.com/2013/01/01/enter-should-submit-forms-stop-messing-with-that</id>
<content type="html"><![CDATA[<p>I try to do most of my work and play on the internet with the keyboard. In the course of my internet-ing there's one unfortunate trend that I've noticed; an increasing number of sites are not allowing the enter key to submit a form. Before I tell you why you care, let's look at how this should work.</p>
<!--more-->
<h3>Enter = Submit</h3>
<p>Take the following basic form:</p>
<p>``` html
<form></p>
<pre><code><label for="name">Name:</label>
<input type="text" name="name" id="name">
<input type="submit" value="Submit">
</code></pre>
<p></form>
```</p>
<p>If you have focus in the textbox and hit enter, the form will be submitted automatically. This behavior is consistent across all browsers and is known as implicit submission. So why is this important?</p>
<h3>Accessibility</h3>
<p>Implicit submission is vital to assistive technologies and impaired users that cannot use a mouse at all. From the HTML5 specification:</p>
<p><blockquote><p>There are pages on the Web that are only usable if there is a way to implicitly submit forms, so user agents [browsers] are strongly encouraged to support this.</p><footer><strong>HTML 5 specification</strong> <cite><a href='http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission'>www.whatwg.org/specs/web-apps/…</a></cite></footer></blockquote></p>
<p>The spec strongly encourages browsers to allow implicit submission; they all do.</p>
<h3>User Expectations</h3>
<p>Many users have an expectation that implicit submission will just work. Interfering with this leads to a negative user experience for these users.</p>
<h3>How to Prevent Implicit Submission</h3>
<p>What are sites doing to keep this from happening? Here's a few things I've seen.</p>
<h4>No Submit Buttons</h4>
<p>Many sites do not have a submit button within the form. From the spec here's how browsers determine what to do when enter is clicked.</p>
<p><blockquote><p>If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.</p><footer><strong>HTML 5 specification</strong> <cite><a href='http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission'>www.whatwg.org/specs/web-apps/…</a></cite></footer></blockquote></p>
<p>Basically, if the user hits enter when a text field is focused, the browser should find the first submit button in the form and click it.</p>
<p><blockquote><p>If the form has no submit button, then the implicit submission mechanism must do nothing if the form has more than one field that blocks implicit submission, and must submit the form element from the form element itself otherwise.</p></p><p><p>For the purpose of the previous paragraph, an element is a field that blocks implicit submission of a form element if it is an input element whose form owner is that form element and whose type attribute is in one of the following states: Text, Search, URL, Telephone, E-mail, Password, Date and Time, Date, Month, Week, Time, Local Date and Time, Number</p><footer><strong>HTML 5 specification</strong> <cite><a href='http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission'>www.whatwg.org/specs/web-apps/…</a></cite></footer></blockquote></p>
<p>So, in a form with no submit buttons, implicit submission will be done if only one input is present. Therefore, pressing enter in this textbox will submit the form:</p>
<p>``` html
<form></p>
<pre><code><label for="name">Name:</label>
<input type="text" name="name" id="name">
</code></pre>
<p></form>
```</p>
<p>But in this form it will not because there are multiple fields:</p>
<p>``` html
<form></p>
<pre><code><label for="name">Name:</label>
<input type="text" name="name" id="name">
<label for="address">Address:</label>
<input type="text" name="address" id="address">
</code></pre>
<p></form>
```</p>
<p>Therefore, if you have a form with more than one input field, always include a submit button. Specifically an <code><input></code> with the <code>type="submit"</code> attribute, or a <code><button></code> element should be present. (Note: IE7 has a bug where the <code>type</code> attribute of a <code><button></code> defaults to <code>button</code> instead of <code>submit</code>. Therefore for IE7 compatibility you'll need <code><button type="submit"></code>.)</p>
<p>If you need to run some JavaScript before the form is submitted (validation, data manipulation, etc), do it in a <code>submit</code> event handler on the form, not a <code>click</code> handler on a button.</p>
<h4>No <form></h4>
<p>I've seen a few forms that do not use the <code><form></code> HTML tag. Why would they do that?</p>
<p>With modern day browsers and JavaScript libraries it's easy to send data to the server via AJAX. Because an AJAX request does not require a true <code><form></code> tag, it is often omitted. However, much like implicit submission, surrounding form data with a true <code><form></code> tag is vital for accessibility. Most screen readers have a <a href="http://www.htctu.fhda.edu/trainings/manuals/tutorials/readweb/forms.htm">mode specifically for filling out forms</a>, and by omitting a true <code><form></code> tag you risk this mode not being activated.</p>
<h4>Explicit Prevention</h4>
<p>Finally, it's also quite easy to prevent implicit submission in JavaScript. Take the following example:</p>
<p>``` html
<form></p>
<pre><code><label for="name">Name:</label>
<input type="text" name="name" id="name">
<input type="submit" value="Submit">
</code></pre>
<p></form></p>
<script>
document.getElementById('name').addEventListener('keypress', function(event) {
if (event.keyCode == 13) {
event.preventDefault();
}
});
</script>
<p>```</p>
<p>This sets up a <code>keypress</code> event handler that prevents the default action (implicit submission) from occurring when the enter key is pressed.</p>
<p>This technique can be handy. For example, say you have a form with multiple submit buttons. As we saw earlier, the implicit submission algorithm will click the first submit button that it finds. Therefore, if you need control over which submit button is clicked, you can use the above technique to listen an for enter keypress, prevent the default action, then explicitly click the appropriate button.</p>
<p>Take the following example:</p>
<p>``` html
<form></p>
<pre><code><label for="age">Age:</label>
<input type="number" min="0" max="120" name="age" id="age">
<button id="child">Child</button>
<button id="adult">Adult</button>
</code></pre>
<p></form></p>
<script>
(function() {
var age = document.getElementById('age');
age.addEventListener('keypress', function(event) {
if (event.keyCode == 13) {
event.preventDefault();
if (age.value > 20) {
document.getElementById('adult').click();
} else {
document.getElementById('child').click();
}
}
});
}());
</script>
<p>```</p>
<p>When enter is clicked in the number input, the <code>keypress</code> event handler determines which submit button is appropriate and clicks it.</p>
<p>While this technique can be handy, I've seen it used plenty of times to completely prevent implicit submission from working. Don't do that.</p>
<h3>Conclusion</h3>
<p>When filling out a form, pressing enter in a textbox should submit the form. This is known as an implicit form submission. Despite being vital for assistive technologies and an important user convenience, many web forms prevent it for one reason or another. If you write web forms, please take a minute to ensure that the enter key can indeed be used to submit them; it'll help make the web a better place for everyone.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Creating Cross Browser Scrollable <tbody>s - A CSS Only Approach]]></title>
<link href="http://tjvantoll.com/2012/11/10/creating-cross-browser-scrollable-tbody/"/>
<updated>2012-11-10T15:44:00-05:00</updated>
<id>http://tjvantoll.com/2012/11/10/creating-cross-browser-scrollable-tbody</id>
<content type="html"><![CDATA[<p>By default the <code>overflow</code> CSS property does not apply to table group elements (<code><thead></code>, <code><tbody></code>, or <code><tfoot></code>). <a href="https://developer.mozilla.org/en-US/docs/Firefox_4_for_developers#Miscellaneous_CSS_changes">As of Firefox 4</a> this behavior is consistent across all browser implementations.</p>
<p>Therefore, if you attempt to apply a CSS <code>height</code> and <code>overflow: scroll</code> to a <code><tbody></code> it will have no effect in modern browsers. You can see this for yourself <a href="http://jsfiddle.net/tj_vantoll/vU494/">here</a>.</p>
<p>But having a scrolling table body with fixed headers is a useful UI element, so how do you work around this?</p>
<!--more-->
<h3>The Solution</h3>
<p>Here is my solution:</p>
<p><pre class="codepen" data-height="400" data-type="result" data-href="JEKIu" data-user="tjvantoll"><code></code></pre>
<script async src="http://codepen.io:/assets/embed/ei.js"></script></p>
<h3>How does it work?</h3>
<p>The first step is to set the <code><tbody></code> to <code>display: block</code> so an <code>overflow</code> and <code>height</code> can be applied. From there the rows in the <code><thead></code> need to be set to <code>position: relative</code> and <code>display: block</code> so that they'll sit on top of the now scrollable <code><tbody></code>.</p>
<p>That's really about it.</p>
<h3>Unfortunate Part #1: Old Internet Explorer</h3>
<p>When you set a <code>height</code> on a <code><tbody></code> Internet Explorer < 10 applies that <code>height</code> to every table cell, which is of course wonderful.</p>
<p>My workaround for this is to conditionally create a wrapper <code><div></code>. When it's present I give it the <code>height</code> and <code>overflow</code> and remove the <code>height</code> from the <code><tbody></code>.</p>
<p>``` html Wrap table for IE</p>
<!--[if lte IE 9]>
<div class="old_ie_wrapper">
<!--<![endif]-->
<pre><code><table>
<!-- Contents of the table -->
</table>
</code></pre>
<!--[if lte IE 9]>
</div>
<!--<![endif]-->
<p>```</p>
<p>The headers will scroll with the table body, but the table will at least be usable. You could also create <a href="http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/">conditional classes on the <html> tag</a> to handle this as well.</p>
<h3>Unfortunate Part #2: Widths</h3>
<p>Because the <code><thead></code> is relatively positioned each table cell needs an explicit <code>width</code>.</p>
<p><code>css
td:nth-child(1), th:nth-child(1) { width: 100px; }
td:nth-child(2), th:nth-child(2) { width: 100px; }
td:nth-child(3), th:nth-child(3) { width: 100px; }
</code></p>
<p>But unfortunately that is not enough. When a scrollbar is present browsers allocate space for it, therefore, the <code><tbody></code> ends up having less space available than the <code><thead></code>. Notice the slight misalignment this creates:</p>
<p><img src="/images/posts/2012-11-10/Alignment-Issue.png" title="Alignment issue with scroll bar" alt="Alignment issue with scroll bar" /></p>
<p>The only workaround I could come up with was to set a <code>min-width</code> on all columns except the last one.</p>
<p><code>css
td:nth-child(1), th:nth-child(1) { min-width: 100px; }
td:nth-child(2), th:nth-child(2) { min-width: 100px; }
td:nth-child(3), th:nth-child(3) { width: 100px; }
</code></p>
<h3>The Good</h3>
<p>Despite these issues the solution does work in all browsers back to IE6 with no JavaScript dependency.</p>
<p>The markup to create the table is simple and semantic. I've seen workarounds for this issue that use <code><div></code>s instead of <code><table></code>s or multiple aligned <code><table></code>s and those always felt dirty to me.</p>
<p>The code is free to use and do whatever you want with it. If you have any suggestions for improvements or find any issues please let me know in the comments.</p>
]]></content>
</entry>
</feed>