According to W3Schools the property is used to "align text within elements".
When using it in different ways however, like buttons, it also works perfectly. See this JsFiddle
Is it a good idea to use the align-text CSS property in situations like this or is something else a better solution like putting float: right on the button?
I was wondering if this attribute was intended only for text or if the name was just chosen poorly.
(as pointed out by Ray Toal, the answer is in the official W3C spec)
To be more accurate, it is used to align text and inline elements within their parents.
So spans, buttons, elements with display:inline-block and so on will be aligned according to text-align, whereas block-level elements are unaffected (but may inherit the container's text-align and apply it to further descendants).
Your use of text-align is perfectly fine here. Using floats would then need to clear following elements from their effects, etc
Perfectly fine: I wouldn't say that of the HTML code of your example (table, no label, no for/id association)
Related
I'm making a rich text editor which is like a clone of Google Docs. For reasons I won't get into here, each line in the text editor is wrapped into its own div container. For example, if there's 3 lines of text, there will be 3 child "line nodes" (rendered as an unstyled div) in the text editor. And within each line node there are inline span elements to control styling such as Bold, Italic, etc.
The issue I'm having is I can't understand why there is an unsightly vertical gap of whitespace between each line when selecting text over multiple lines. I am using Draft.js for this, but from what I can see it shouldn't make a difference; there's no styling or margins applied. I've even tried making every line div and its span elements exactly the same height but the problem persists.
My guess is this is caused by some native browser behaviour. All I really care about though is: can I "fix" it? I mean, I know it's possible because Google Docs doesn't have this spacing issue when selecting text... But then again it uses a completely custom rendering engine with custom cursors too. Thanks for any suggestions
edit: so a temporary workaround I've found (see image below) is to reduce the height of each div and span to a fixed value (in this case, height: 16.4px). But for obvious reasons, this isn't an ideal solution. I'm still looking for a "proper" way to implement whatever styling I want and not have these gaps appear between adjacent divs when selecting text
I believe your talking about line-height in which you can control the space between two elements / texts.
Try it out below:
div {
line-height:100px;
}
<div>Hello World!</div>
<div>How are ya?</div>
Thank you for all the suggestions. Turns out this is quite a challenging issue and there's very little (if anything) that can be done with pure CSS. Only the height attribute of div or span elements appear to have any visible impact on text selection. Inspecting the Google Docs elements reveals they use their own custom selection engine:
Closing this because I at least know how a solution might be implemented now, even if it would be very complex and time-consuming. Thanks again for the suggestions.
I set up a search box using divs and floats to create a multiple column layout. My IE 7- clients see a line break between the filter-label and filter-input-controls.
They have corporate policies that won't let them upgrade or use Chrome or FF. I tried using a clearfix and a comment before the doctype. No luck.
jsfiddle here
Consider using LABEL tags and a styled, unordered list, as a container for your form elements. This results in cleaner code and it makes more semantic sense.
See: http://alistapart.com/article/prettyaccessibleforms
It looks to me like your "Deviation Status" span is in a different div than your select, one would expect them to be displayed in different block elements. As I don't see "display:inline(or inline-block);" anywhere in your CSS, it doesn't look like you are accounting for this default behavior..
Looks like your search box is too wide. Try adding a *width: to the containing div. The * is a filter for IE7 and below.
IE7 will need everything spelled out layout wise (width, height, float, etc). If one element is too large, it will break the layout. More modern browsers are more forgiving.
This problem is easier seen than described. See here: jsFiddle
To get a clearer understanding of what is going on, I have updated the fiddle to include a class .ui-sortable-placeholder to be visible and red. This is the class of the jQueryUI (normally) invisible element involved with the sortable. As seen here: http://jsfiddle.net/rLW9m/9/. Thanks to George for pointing that out in his answer. With this answer we can probably consider this resolved as far as the "what" but perhaps the "why" is still TBD.
Of the three scenarios shown, they all apply float:left to the LI elements but the final one behaves poorly; in the last bunch of sorted items, clicking on the first or second item "drops" the rest of the list beneath the row they were just in (and the item clicked).
The scenario is exhibited when the float:left CSS is applied directly to my <li>s using inline styling versus applying the same change via a css file. Is this a jQueryUI bug?
When I apply the CSS to my elements in the identical way to how jQueryUI's documentation shows (the first example in the jsFiddle), then the sorting occurs just fine. However, once the same CSS (as far as I understand it) is applied directly to my list items, then sorting behavior is erratic as described above.
The way to get jQueryUI to sort nicely in a grid is to apply the float only in your CSS file using classes or other mechanisms:
/* Starting from UL descriptor with LI descendants */
.ulClass li {
float:left;
}
/* or directly to LI element but still via CSS file */
.makeTheseLIsSortable {
float:left;
}
/* DOES NOT WORK properly to directly apply CSS
(items to the right are shifted below when items on left selected) */
<ul id='makeSortable'>
<li style='float:left'>test</li>
<li style='float:left'>three</li>
</ul>
Why are these two CSS applications handled so differently by jQueryUI? When it is rendered, it sure seems like the list elements themselves are float:left either way. What is your take? Why can't I apply the CSS directly to the list elements and get the same, expected behavior?
EDIT: Thanks to George, I now have a better understanding of what is going on. There are probably some really good reasons that jQueryUI doesn't copy down the element inline styles to their "placeholder element" but they do pass along class details. If a jQueryUI pro shows up later and considers this a bug then I'm glad to have reported it. Until then, be sure to apply your sortable element's float via a class! Can you explain why the inline styling is not included into the placeholder?
The problem is the place holder that jqueryUI inserts does not have a float left style on it. jQueryUI duplicates the element type and the classes on an item you are sorting for the place holder but it would appear it does not duplicate the inline styles.
The div is the quintessential block level element, and the span is the inline counterpart. They are the simplest possible form of that display type, with no other properties. In a great many cases I will give either of them the style:
display: inline-block;
This makes them behave in a very handy way. For div it means boxes that will easily sit next to each-other, while maintaining their width and height as defined. For the span I can use this to make colorful rectangles. The inline-block display is great for so many things, but I have never seen an element that starts as an inline-block without anything else going on.
Images (img) are, but they are obviously not suited for the same things as a div, they have that style, but they fulfill a different purpose.
So is there an element that I don't know of that is the quintessential inline-block, or is this left out?
And if not, why? The uses of inline-block are numerous, so it seems like there should be some element that takes that basic form.
There's no such element, and there are some good reasons why not.
inline-block has several uses in contemporary web design. However it is not part of the original design, which only includes block and inline elements. Instead it derives from <img> as added by NSCA Mosaic. (Which uses the wrong markup and helped defeat the original "responsive design". I think we've only just started to fix the problems with img).
Further down the timeline, inline-block still wasn't part of IE4 or 5, or any version of Netscape. It wasn't part of the early HTML4 era. So we wouldn't expect to find your hypothetical element in that version of the standard. inline-block only appears in CSS2, which came after HTML4. (Look at the reference section in each standard).
Unlike block, inline-block is affected by whitespace in the markup. It's implied by the name, and it's what you'd expect from looking at <img> in the middle of some text (aka wordprocessor object anchored "as character"). But beyond its origins there, the whitespace-dependent markup soon becomes very troublesome. I wouldn't expect W3C HTML5 to enshrine this in a new element.
Specifying it would certainly involve argument about "semantics", separation of content and presentation etc. (As well as what to call it :). And if the default rendering makes whitespace significant - is that not part of the semantics of that element? Consider using images to represent words - or individual letters of a word (with appropriate alt text). This illustrates that the presence of whitespace (or not) around this element would be semantically significant, just like the presenceofwhitespaceseparatingwordsissemanticallysignificant. That seems like a big problem to me.
inline-block is often promoted as a modern alternative to using float everywhere. But neither is genuinely suitable. This is why CSS3 will standardize new layout modes: "flexbox" and "grid", to support modern responsive designs with genuine, clean markup. No dummy markup (or dummy generated content). No hacking around whitespace-dependence.
The only elements I can think of that have an in-line appearance, but allow for a width and height to be set, are:
img,
input,
textarea
select, and
button
The only element here, though, that can take HTML content is the button element; which is not an ideal use of the button since it's intended to be an element with which the user might/should interact; rather than simply a container element.
While you may have multiple uses for such an element, there's no convincing reason, given the ease with which the display property might be changed, that the W3C, or any other authority, should explicitly define one; especially given that the only difference between inline and inline-block is the ability to assign dimensions and margin.
The img tag is inline-block by default:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
Edit: You can check this SO question: Is <img> element block level or inline level?
Why is it like this?
What's the reason inside it?
When you float it, you implicitly make it a block element. And unlike inline elements (a included among these), block elements can be assigned a width and height. Here's a good explanation of block vs. inline differences.
Edit: removed "have layout" as part of description of block elements, this isn't quite true...
<a> is an inline element and flows amongst regular text. As Ben says, floating elements implicitly converts them to "block" elements.
One solution is to use the CSS style display: inline-block - the link will then work much like an image - flow inline with text, but also allow you to set a width/height.
The premise is incorrect.
use an inline-block
abc