Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a custom control I built that contains a list of items to be selected.
I was concerned that these items would run together seeing as how there can be many different types of actions in this list.
Create
Edit
View
So I made the ability to separate these into groups by using a horizontal rule.
Someone I work with thinks that horizontal rules are a terrible design choice, and wants me to change it to a stylized DIV. I do not really have an opinion other than they are simple to implement. The HR I implemented is styled nicely and looks good.
Thoughts? Are horizontal rules a good or bad design choice?
Bad, and so is using a div simply for adding a horizontal div. Instead, consider putting the line which looks like horizontal rule as a border to the element you want to divide. This will be semantically correct as you are not affecting the structure of the HTML document you are creating.
This article goes in to depth about how div's can be abused by using them as presentation elements only. While sometimes there is no avoiding it, this is not one of those times.
I tend to agree with altCognito on this point, because they're purely presentational (at least they seem to be in every instance in which I've seen them used so far) they should be applied via the css.
There may well be a :after {content: /* hr */;} option, but, honestly, when there's border-bottom, which visually serves (or at least can serve) the same purpose, why bother with the <hr /> anymore?
They can, of course, be styled if you do decide to go with it, although W3 Schools suggest that all the potential styling options are now deprecated. If this is so, and it can't be 'officially' styled, it'd be best to avoid it, I think. Even if only from a purist mentality to maintain validity of your stylesheets.
The only problem with the HR is that it's always there. I'm assuming your co-worker believes that you might not always want the HR to be displayed, and using the DIV and a css solution let's someone remove or change it in one global css file. (although, the HR could be controlled by css also)
The div+css solution isn't a bad one, but for what you describe, the HR solution isn't bad either. I'd just go with whatever is convenient in this case.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
When creating close buttons, usually for a card of some sort, I often find the need for some visual symbol resembling the cross/multiplication symbol we all associate with closing things.
In most cases, I find myself preferring to use the HTML entity.
×
But I've seen use of the "regular" x key on a traditional EN keyboard. As well as SVGs like those available at Feather and Hero Icons, so on.
What I would like to ask is whether there is a recommended option amongst these, and why? And if not, which option is most widely supported and/or most performant?
Thanks
Some background below, not necessary to read:
The Entity felt the best bet for me, for a while. I was a fan of having to load or package one less asset into my app, however small, if I had the opportunity. This and, I'd assumed that what is the "x" key on my keyboard might mean different things and be different codes to different encoders across the wider world. ×(;) will only ever be ×(;). That's my hope anyways. That said, I've noticed some issues with what appears to be irremovable padding of that entity; whitespace above and below the character which grows rather large as the font size increases. As a result CSS cursor effects fire prematurely, at a point where the cursor is significantly (visibly) far from the symbol proper. That and the inability to adjust the equivalent of the 'stroke-width' property for that symbol have me wondering if these newfangled SVGs, and all the unique features they bring, might be the best choice here regardless. `
Based on my experience (as this seems like an opinionated topic), I don't think there is a recommended best practice. In the beginning, to achieve a working state, I would use a capital X since it's universally supported. Later on, the use of a SVG would be a good option primarily because SVGs are easily scaled for any device and are supported practically universally.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been thinking about this for a few days and wondered which would be the better layout option for making a forum: Tables or Divs?
Now to be specific, there are a few criteria here:
It will be in the familiar tabular presentation most forums use, such as the phpBB default theme.
It must be able to be responsive, ie if you want columns to be hidden at certain screen sizes, the whole row must be clickable, etc.
It must be easily re-stylable for custom skins.
My initial thought is that tables tend to have issues in responsive layouts, and the typical forum layout can be accomplished via divs, though they may require somewhat hacky approaches depending.
Is there really a benefit to either format? Would a Table layout be easier for a search engine to crawl? I'm trying to avoid too much opinion based points such as preference of divs over tables, unless there is a really strong case for it.
EDIT
There seems to be come confusion as to my question so I'm going to clarify. My question is not about the website format in its entirety. In fact, the project this is for is utilizing bootstrap. My question is: are there advantages to using tables for the Forum layout, ie where the forum categories are listed, the threads are listed, etc. These things are practically tabular data. What about tables for that. It's not purely data, but it is still somewhat tabular in its nature.
Once again, my question is not to discuss the merits of Tables for web page layouts, as the "Possible Duplicate" suggests.
maybe just flex-box ?
A Complete Guide to Flexbox
This may just be my personal opinion, but I think tables were made to structure data. Yes, there was a time when tables were heavily used for layouts but I guess we're all glad that those times are over.
Your site should be semantically correct, not only syntactically. I think this sentence sums it up pretty well:
"Tables should not be used purely as a means to layout document
content as this may present problems when rendering to non-visual
media. Additionally, when used with graphics, these tables may force
users to scroll horizontally to view a table designed on a system with
a larger display. To minimize these problems, authors should use style
sheets to control layout rather than tables."
http://www.w3.org/TR/html401/struct/tables.html
There are UI frameworks that do the job very well (in fact Bootstrap's column oriented approach is very close to a table) and I am quite sure that you will achieve the desired look using semantically correct tags. I am not a SEO specialist but I think that tables are not what you're shooting for in case of crawler friendly semantics.
It depends on the level of browser support that your looking for. Flex-box only works in IE 10 and above. There's options like display:table-cell (to attempt to make the element behave like a td table element), but again it has limited browser support for older browsers.
Tables should be kept for tabular data, and not used for layout, especially when there's tons of frameworks out there now (like Bootstrap) which will handle it for you.
One thing I have found really cool is Masonry.js, which rearranges the elements on a page to find the position for them based on their size and the size of other elements around them. It works in IE8 and above, and all other major browsers. The only downside is that it requires javascript where as Flex-Box (which gives a similar result) does not.
Alternatively you can write your own css for table layout, using a grid structure (similar to Bootstrap) where you have a set 12 column layout and rows containing cells which span across 1 - 12 columns.
Using a <div> can help too in making a layout responsive and table-like. You just need to change div properties a bit and you can use it as you are using tables! Here is the major change which can be done to transform <div> to table-like form
<head>
<style type="text/css">
.div { display:inline-block; }
</style>
</head>
<div class="div">Hello</div> <div class="div">World!</div>
display:inline-block; will force all div with same property to get in one line.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The website I'm making is for an author/illustrator and she wants words in the navigation bar to be written in her own handwriting, so the links in the navigation bar and her own name, which serves as the title, are all in the form of pictures rather than text.
Similarly, the homepage consists of some of her illustrations, each accompanied by a handwritten link, so that there is no text at all. I'm starting to realise from reading online that this may be seen as 'bad practise', so I want to ask those with more experience than me: how problematic is the lack of text?
I am not too worried about loading times and such - I've managed to make the image files quite small - but more things concerning accessibility and whether the site will appear in search engines.
And are there any ways I can avoid problems whilst still using the handwriting?
When you want to use images as navigation elements and are concerned about SEO and accessibility, you can use the alt-tag which you should use anyways.
Example:
<img src='images/nav1.png' alt='Home' />
Screenreaders and search engines use these tags to deal with images which they of course can not read.
There are two issues here. First, people who do not see images (for one reason or another) will find the site almost impossible to navigate, unless the img elements have alt attributes. Correctly written alt attributes resolve this problem and can be expected to provide adequate information to search engines as well. Second, people who use normal graphic browsers will see the texts in a specific appearance. This may mean that they find it less legible than normal text, perhaps even illegible. This greatly depends on the style of the text, including size and the contrast between text and background color.
If a downloadable font were used instead, via #font-face, then the latter problem would in principle be less severe, since users could disable page fonts and see the text in their preferred font. This is rather theoretical, though, and creating a font is nontrivial and probably not worth the effort here.
On the practical side, write the alt attributes and ask the author consider whether the font is legible enough to all visitors, including people with eyesight problems. It’s up to the author to decide whether the reduction in usability and accessibility is justified by the artistic impression made.
You can choose from many handwritting fonts and link them via #font-face.
If she wants to use her 'font', use images (ideally one image - looking for sprite) and put text underneath - it's call image replacement.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I recently got into the discussion that float can be used in layout design, but should not be used for layout design. To specify, it can be used to float certain elements, but not position entire semantic sections and containers with respect to each other. Although the individual cited a couple sources (source 1, source 2) that could lead one to believe that float is hard to work with in some layout situations, I don't see any evidence linking to a specification to support the claim that it should not be used for layout.
If you can use float to position small portions of your layout, why not extend this technique for the big picture? i.e. the whole layout.
I know there are new techniques coming out like the flexible box layout and some others, but they are still drafts and are not supported currently. inline-block seems like a good candidate but sometimes you just need that float fix, and there are hacks to get this to work in older browsers as well.
So I guess my question is... is it true that float should not be used for layout? Is it a non-semantic or outdated technique nowadays, akin to the table layouts of yesteryear?
Semantics in the jargon-sense are simply a way of formatting HTML so that search engines can parse the data with some sort of context. Semantics in a broader sense is how you code your site so that other developers can pull meaning from your coding style.
Floats are simply a tool in your tool belt and have no semantic context whatsoever. Additionally, floats are so widely used that it would be incongruous to say that they shouldn't be used. There are plenty of frameworks that rely on floats as part of their integral structure (Bootstrap, Gumby, Foundation, Skeleton, etc).
I can speak, however, to the difficulty of using floats. For someone just starting with CSS it can be hard to understand what exactly is going on with floats. In addition, you have clearing and in-flow and out-of-flow elements. It can certainly be confusing. However, floats are absolutely a cornerstone of the CSS specification and I couldn't imagine doing my job without them.
Hope this helps!
Bootstrap is heavily dependent on floats, and its probably the most used CSS library. That being said, for every fan of bootstrap, theres someone there to say that its not best practice.
Do what works for you
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a script that is programmatically formatting web content. Because the content is generated in a WYSIWYG editor that I have no control over, all new lines of text are exported as <div>s.
My very first gut reaction is DON'T DO THAT! But why? There's nothing exceptional about the <p> tag. I am concerned about any potential problem. I'd rather not waste the effort selectively adding <p>s in code if I don't have to.
This got me thinking...
SEO: Will google hate me for it?
Accessibility: Will screen readers die on this text or ignore it maybe?
Fancy: Will double-tap to zoom break on mobile devices?
Similar but different: Using custom HTML Tags
INB4 somebody complains about IE.
p tags do actually behave radically different than div tags, which is sadly beyond your control since this has to do with DOM parsing rather than CSS. Thankfully, you will most likely run into less problems with div tags than the former.
Even though p tags are block elements, they are defined to only be allowed to contain phrasing content. In reality, this means that they can only contain elements whose default display type is inline. Browsers will thus literally refuse to render e.g. div tags inside a p tag no matter what CSS you apply. div tags, however obviously don't have this restriction.
The only thing that I know of that differs to the favour of p tags, is that they don't require a closing tag if directly followed by one of a select few different tags (e.g. other p tags)
Other than that, there are no drawbacks in using div tags that I know of, and you are free to use whatever you want.
div tags will still let search engines index your text. Custom tags can be dangerous (especially on older browsers), but divs are widely supported. While there are some potential semantic differences, I doubt you would run into issues.