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.
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 6 years ago.
Improve this question
I'm currently placing some ID's on elements for UI Test automation. These ID's are only being used for testing. Should I be adding data-attributes instead possibly making it more readable to future developers(data-testHandle="mybutton") or should I stick with ID's.
w3.org says:
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements.
I'm leaning towards keeping ids but some part of me thinks that future developers would think the ID's aren't used and remove them.
Any best practices here. Thanks.
This is close to being opinion-based, by here is the summary that should help to make a choice.
Why would you use an ID attribute:
this is a common and familiar to everybody doing test automation way to locate elements
this is generally the fastest way to locate elements on a page because selenium gets it down to executing document.getElementById() which is optimized by the modern browsers (though, usually performance of the end-to-end UI tests is not critical)
it is a built-in locator in every selenium language binding
if you would use Firebug or Chrome Developer Tools - the CSS selector and XPath generation tools would generally provide more robust locators using the ids of the element whenever possible
you would build shorter CSS selectors and XPath expressions. E.g. #myid .someclass as opposed to [automation-id=myid] .someclass.
Why would you use a custom attribute:
if you would add, say, automation-id attributes to all the desired elements, you would somewhat namespace/scope it to the test automation - everybody would know what is this for just from the attribute name. Meaning, you would dramatically decrease chances of a developer changing the attribute intentionally as opposed to an id attribute, which can and is usually used for application client-side logic as well (reference to this and this answer)
Also, here are some relevant threads:
Is adding IDs to everything standard practice when using Selenium?
Which is the best and fastest way to find the element using webdriver? By.XPath or By.ID or anything else? And why?
Something Better than IDs for Identifying Elements in Selenium Tests
I would go with the data attribute instead, as you (or someone else) might need to use an ID for targeting the element for JS later. No one is ever going to need to target your custom data attribute for anything other than testing.
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 off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
This is a question I was wondering about for some time now, but couldn't quite find what I looked for on google.
What I'm wondering is, has there been any competitive markup language to X/HTML, that was essentially supposed to do the same job as HTML, but:
is rendered directly (without actually being compiled down to x/html)
is not just using a borrowed HTML-alike syntax (yes, I'm aware of SGML, which is widely known as the precursor of modern HTML)
The other thing is, I can see why HTML is popular: Its syntax is very easy to learn, no (overly awful) hidden black magic, it's a straight away markup language that does exactly what it says on the tin.
When people think of markup languages, they usually think of HTML. Markdown is compiled to HTML, so is every wiki syntax semi-language. But there has got to be someone (or some company) who had a similar idea, and thusly tried to create a markup language that would fulfill similar, if not the same requirements.
I find it kind of hard to believe that there has never been any competitive markup language. Or has there really never been any?
1) TeX
2) http://en.wikipedia.org/wiki/List_of_document_markup_languages
Well, there’s Rich Text Format which, although as far as I know never developed to be written by hand, nevertheless is human readable:
{\rtf1\ansi{\fonttbl\f0\fswiss Helvetica;}\f0\pard
This is some {\b bold} text.\par
}
On the other hand, there’s PostScript which, while also being a Turing-complete programming language, is used to mark up documents.
%!PS
/Courier % name the desired font
20 selectfont % choose the size in points and establish
% the font as the current one
72 500 moveto % position the current point at
% coordinates 72, 500 (the origin is at the
% lower-left corner of the page)
(Hello world!) show % stroke the text in parentheses
showpage % print all on the page
I’m sure there are more languages in the same vein. Looking for related articles on Wikipedia, InterPress comes up, for instance.
You might find http://www.w3.org/MarkUp/historical interesting.
There are loads of other document formats and markup languages but they don't really compete directly with HTML as such. Any potential competitor would have to overcome the fact that HTML (+CSS+JS) has become a sort of "universal language for everything" (i.e. it runs on everything, everywhere).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is there any way to decrease or squish the size of a .html page?
If we are talking about size of the file in bytes, then gzipping it on-the-fly will have the biggest impact. After that, I'd suggest removing whitespaces and comments, and moving all inline javascript and css into separate files. Then you may consider trying to clean the HTML a bit, like removing tables in favor of divs and all that.
Then, if you are really going to push the limits, you may try to change your doctype to HTML4 Transitional and then exploit its un-strictness. You can remove <body> tag, you can stop closing <li>s and <td>s, you can drop off parentheses around tag attributes or remove whitespaces between them, and still remain valid. Also, if you replace all your <strong>s with <b>s, you can save up to 10 symbols per pair! :)
If you need a working example of that "pushing the limits" techniques, then go to http://yandex.ru and explore their sources. Yandex is the leading search engine in Russia, they really care about the size of their index page and they know a lot about optimizing the code and load speed of pages.
Assuming you are talking about the length of the page in bytes:
Make sure gzip is enabled on your
server.
Remove comments.
Remove any
Javascript and css - Javascript can
be compressed in a separate file using a tool such as googles closure compiler.
Use ansi ascii or UTF8
encoding (as opposed to UCS2/UTF-16).
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.