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 8 years ago.
Improve this question
Is CSS text-transform expensive in terms of processing? It appears to me that the browser's being forced to do some work that it wouldn't normally need to (if you didn't transform), but is that a significant amount of processing? Does it impact performance at all?
It might take a bit more processing from the client's browser, but this will be totally insignificant unless you're transforming pages and pages of text (and if you're doing that, you're doing something wrong).
You also have the overhead of having the CSS property written in your stylesheet (heavier file), but once again it's only a few characters and shouldn't make any difference.
I got curious so I ran some basic benchmarks. On Firefox 3 I displayed a page with 200 paragraphs of Lorem Lipsum.
Rendering it will take between 0.150s to 0.175s
When adding text-transform:none I don't see any significant difference.
When adding text-transform:uppercase it now takes between 0.350s and 0.380s
When adding text-transform:capitalize it now takes between 0.320s and 0.350s
When adding text-transform:lowercase it now takes between 0.320s and 0.350s
So apparently we do have some overheads processing this, but once again I'm capitalizing hundreds of lines and it only costs 0.2s. Therefore if I were you I'd use it without thinking about performance too much unless you want to text-transform huge chunks of text.
If you're designing for mobile, every little bit helps. If it's not dynamic, then type it out in uppercase
I don't see any reason why it should be any more 'expensive' than any other CSS style. All it does is convert a string to upper/lower case, which is hardly the most taxing process a computer can be asked to do.
I'd compare it with displaying in italics or bold; both these styles effectively change the font for the entire string, but you wouldn't consider not using them in case it's processor intensive for the browser, would you?
The only time you could even conceivably think of text-transform as having a hard time would be if you're using a non-latin character set, in which case converting to upper/lower case may not make sense. But you can be pretty sure the brower makers have got that covered. (and in any case, if you're in that position, why would you even want to use text-transform?)
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've seen many people suggesting setting *{ margin:0;padding:0;}. It does prevent lots of unexpected margin/padding on the page.
But if it's first thing we ought to implement every time we create a CSS file, why do the browsers bother to set default element margin/padding other than 0?
I guess giving a default margin makes sense to elements like <p> to keep the paragraph spacing. But again, if we are suggested to put the * reset every time, the browsers' default settings don't matter anyway, right?
There really is no exact answer to your question. But, the most logical reason to put a preset margin and padding is to most likely make webpages automatically more appealing to the user. If you see a website with text right up against the side of a page, it starts to look a little stretched and sketchy. So, to counter this, they set a margin and padding.
Bryce
A <h1> in example unfortunately has a browser-specific margins (see specific to the browsers). Setting margin/padding to 0px is a poor version of a normalizer that redesign all css to a clean cross-browser design from what you can start to write css that let the browsers render the same style.
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 7 years ago.
Improve this question
I'm originally an iOS and mobile engineer and recently, I've been getting back into web development. In an attempt to dive as deep as I can into it, I've learned as much as about things like Webpack, more advanced SCSS, React, Redux, etc. After all my research, I'm still left with one burning question.
Why should I use HTML, specifically HTML5, elements in my markup vs creating all custom elements (such as a header using divs not header, wrapping dates in <time />, nav elements, etc). As an iOS engineer, I often find that design requirements make me build custom views with little to none built in view components and if I do, they're often my own components I've built from UIViews (equivalent to div, ish). In web development, unlike mobile, there are so many built in elements and I assume there's reason for that.
To ask it another way:
1) Are there specific performance advantages to integrating more HTML5 elements into my markup?
2) Are the advantages purely semantic? That is to say does using the built in elements more provide my website with better semantics and readability at first glance?
3) Is there an accessibility advantage to using built in elements?
It seems that this would be the primary reason to use HTML5 elements. Supporting accessibility is really just an extension of good user experience and that's always worth implementing.
4) If I do use HTML5 standard elements more, wouldn't that introduce some risk into my projects?
By risk I mean introducing unintended behavior. If I use a all divs and only divs in my markup, I have predictable element behavior across the board, especially when it comes to styling. All divs are equal in that respect. If I use a HTML5 element that I haven't read up on fully, would I not risk injecting unwanted (not necessarily harmful though) behavior?
I see your point and I have never really put much thought into this. However after looking through some articles and sources the general consensus is that there is no evidence that using custom elements causes any performance issue's over the standard HTML elements. However there is a few sources that say stick to some sort of guide line for the purpose of semantics correctness.
Are there specific performance advantages to integrating more HTML5 elements into my markup?
1) Not particularly, there is hardly any performance problems with markup that I have run into on multiple platforms.
Are the advantages purely semantic? That is to say does using the built in elements more provide my website with better semantics and readability at first glance?
2) Yes and no. Following the HTML5 element markup does make it easier for other developers to find a bug or to refactor the markup at some point down the line. And no HTML isn't purely for the semantic side of things although semantics do make things easier in a verity of different ways, in terms of SEO and how the browser reads the site for screen readers is vitally important to creating a fully accessible site on the web.
Is there an accessibility advantage to using built in elements?
3) HTML5 makes creating accessible sites easier for two main reasons: semantics and ARIA. The new (some currently available) HTML headings like <header>, <footer>, <nav>, <section>, <aside>, etc. allow screen readers to easily access content. Before, your screen readers had no way to determine what a given <div> was even if you assigned it an ID or Class.
If I do use HTML5 standard elements more, wouldn't that introduce some risk into my projects?
4) I haven't come across this myself so I have no experience on this potential problem.
I would say if you want go for it, but keep in mind the advantages of using mainly HTML5 element's and the disadvantages of using custom element's. I personally most of the time use completely standard HTML5 element's but sometimes I might use my own custom element's for a situation that seems it would benefit from such as makes better semantic sense to write my own element for it versus using an element that might cause confusing later down the line to me and other developer's.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Edit: Resolved. Rather than resetting the Zoom to 100%, the "View < Actual Size" resolved the issue.
I've been having an issue with Chrome rendering divs as fractions and not exactly as the specified numbers.
For example:
HTML
<div class='tile'>foo</div>
CSS
.tile {
background-color: #CCCCCC;
border-width: 2px;
border-style: outset;
display: table;
float: left;
}
Rather than being rendered as 2px, the border-width is "1.8181817531585693px" inferred both from the Chrome Developer Tools > Elements > Computed and using the debugger with jQuery .css function.
A few additional things to note is that this only happens when it's loaded on an FTP, not locally. This issue also doesn't occur in either Firefox or Safari. Any ideas or explanation as to what exactly Chrome is doing, or the solution to it would be much appreciated. Thanks!
The short answer is they are dealing with real numbers that are binary internally, and things must be done quickly.
So some numerical corners are probably being cut, that are normally not noticeable to the average web page viewer, that is if a page is designed so that it is not noticeable.
Go figure, I know, you would think that browsers would be more accurate, but I have found that even with the most careful and detailed control of my css, there seem to be rounding errors that play havoc with small details when displayed.
First, I would suggest you use em rather than px. I know you might have to start over with your css, but I have found it to be more reliable, screen to screen. Remember modern pages are not based on pixels. They are dynamic beasts that can be zoomed in and out, and squished narrower and still must output something reasonable.
Also I would suggest rethinking how you are laying out your page so such small details are not an issue. In carpentry the skilled artisan knows how to hide the rough edges with a molding.
I have a very accurate web page I use to generate to a special printed flyer. It was a royal pain to force html and css into something they didn't want to do, which was be accurate.
Also I can test my production site on the 5 major browsers, right on top of each other so I can see little differences when I switch between them, from one browser to another. They are all off just a little from each other in various ways, and really there is no way to make them accurate.
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 7 years ago.
Improve this question
Once apon a time IE6 lacked support for CSS features such as "display: table-cell" and inline-block, resulting in "float" being hijacked and used for layout - which is was never designed for (or particularly good at).
Using floats seems to result in overly fragile layouts that are difficult to maintain and often break completely with changing dynamic content.
This was a necessary evil in its day, however now that support for browsers pre-IE8 are less of a concern, we should in theory be able to move away from floats and use the parts of CSS that actually work well for layouts - such as the aforementioned display: table-cell and inline-block.
I'm currently considering of recommending my team move away from float based designs entirely - am I at risk of painting myself into a corner and having problems down the line , or is this a better option if older browser support is not important on our project?
Should you move away from floats entirely?
Sure, so long as you don't need the deeper browser support. When it comes down to it, what really matters is whether the page displays properly for the largest numbers of visitors to your site as possible, right?
Another issue that should be of concern to you is maintainability, but I can't say that it'd be accurate to say that either method is less maintainable than the other in every situation. So I'd just ask yourself what layout method your team is more familiar with and how far back you need to support.
display: table-cell is supported in IE8+. Float displays can go all the way back to IE6.
Other thoughts & the future...
Contrary to what you said about floats, I think when used right they can be very predictable. My primary qualm with them is the need to clear the parent which is a bit awkward. Further, popular scaffolding systems like Bootstrap and 960-Grid still choose to use floats, and for good reason: they're useful, have great cross-browser support, and can do what you need to do.
With that said, the future is looking good for Css and layouts. There are two upcoming models of layout in Css: the grid system and the flexbox model. Neither are recommendations yet, so browser support is a bit shaky on them.
The grid system is similar to display: table-cell but gives you much greater control. Flexbox tries to generalize and abstract the idea of displaying elements, which allows for really powerful, fluid (or 'flexible') layouts. Both of these will be pretty amazing once they're implemented in browsers.
If you want to read more on usage of flexbox, I recommend the excellent MDN article about it
Were I you, I'd just hold out and use floats – in particular, by using a scaffolding framework. I haven't worried about writing scaffolding Css in a long, long time; I use frameworks since the code is already written for me. And, for me, I'd only find it worthwhile to completely restructure a project once flexbox and the grid system are a recommendation and more widely implemented.
Like you said is about what is best for your team, but believe me... if you use float correct and in the right places you don't get a layout breaking because you change the div content.
But in the future the best way will be using flexbox, you can accomplish everything about blocks horizontal, vertical, with same sizes, diferrent sizes... Anyway when all browsers support it, will be aewsome.
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 11 years ago.
Improve this question
For the sake of this question, let "efficiency" mean, more-or-less, page rendering speed. Albeit, we should also take into account performance issues, like smooth scrolling.
Let's say you're putting a striped background on a page. From an efficiency standpoint, is it better to tile an image 100px wide (showing ten stripes), or an image 20px wide (showing two stripes)? Of course... a large image takes more time to load, but I feel like I've encountered trouble when tiling very small images. Is there an optimal point?
I'm starting to think this depends on the browser (and maybe the operating system as well?), especially given part two of this question:
To achieve translucency, is it more efficient to tile a translucent .png file, or work with CSS opacity attributes (again, the question of large vs. small tile comes up)? From my experience, older versions of IE seem to behave better with a tiled, translucent .png than they do with CSS opacity attributes (though I've never done any scientific testing).
Rounded corners are another good example... in some browsers, the use of images instead of CSS attributes or JavaScript implementations seems to make the page much faster, with much smoother scrolling.
This is really a question broader than CSS, but it's just something I've been thinking about lately.
-Peter
Yes, this is all OS and browser centric.
For instance, in Safari, it's more efficient to use CSS transformations to animate elements than JS.
In general:
you want to avoid tiling very small images. A 20px image will tile better than a 1px as the browser is doing a lot less work to repaint the entire screen. Likely not much of a difference between 20px and 100px, though.
anything that can be done with CSS will likely be more efficient than loading another image. (such as rounded corners, drop shadows, etc.)
a big caveat is IE's css filters. A lot of those are not efficient and you may be better off reverting to images.
Based on my testing, it seems the page renders faster using the smallest image possible, and let CSS do the tiling for itself. The speed at which this takes place is solely dependent on the browser.
As for translucent backgrounds, using CSS would be lighter on bandwidth, but CSS opacity still isn't fully supported, so I would take that into consideration when tackling something like that.
I'd be very curious to know what the results of other people's testing...