81–90 of 143 posts
Earlier quoted context omitted.
Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...
What potential security vulnerability do inline styles have?
Earlier quoted context omitted.
Or, you know, put it at the bottom of the HTML since it will take 5ms between the moment where the browser receive and
It may take a lot longer than that, since the browser is parsing as it goes. A SCRIPT tag in the HEAD will run synchronously, blocking parsing of the page and delaying initial render. For a tiny script that defers work, this is not a problem. But you want to schedule the stylesheet to load ASAP, in case it is cached, so it's actually potentially a human-noticeable difference to get that function on the queue before t…
A bigger problem is that in some browsers (not Firefox, but iirc yes Chrome) that stylesheet load will then itself block rendering.
Earlier quoted context omitted.
I agree with jdudek here. While I'd never use important, I usually have a lot of small utility classes like bold, italics, uppercase, truncated etc. I don't see what's wrong here - they come in handy when you need a one-time style alteration.
The intentions are baked into your class name, if you were to change the style later and favor underlining rather than bold text, it would require a change to the HTML (or some rather misleading code). The same could be said for a mobile device, where italic could be hard to read, so, say a different font is used. Again this would require changes to the HTML and breaks the separation of style from markup. It doesn't…
I think of this stuff as the equivalent of walking into a job site and finding a dozen surge protectors daisy-chained and clustered together, with everyone there oblivious to the problem. "What? If it works, it works. Don't criticize."
I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)
Vendor-installed SQL server database. In this DB is a table called tblYesNo with one column called YesNo. In the table are the following two rows:
YES
NO
Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure payload size. I'm also beginning to re-think CSS. I love CSS, but just like with OO, I'm thinking it may tempt us to think of structural considerations when we may just be wasting our time. I think the next app I write, I'm going to evolve my CSS, starting with i…
I iterate back and forth between including my stylesheet and not including it, while developing the HTML. I try to get the unstyled layout to make as much sense as possible, to be a complete presentation on it's own, albeit looking like it's from 1995.
I then add styling just to make it look good. Since the flow of the page already makes sense and is readable to a user, the CSS is usually much smaller and less intrusive.
I don't use CSS resets. The entire concept to me is the devil. You're design should not be trying to rewrite the world. You will probably get it wrong if you try.
Earlier quoted context omitted.
Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...
What potential security vulnerability do inline styles have?
I do not understand this particular example. They replace 4 lines of external CSS + 1 line of loading by 1 line of internal CSS + 2 lines of tags + 11 lines of JavaScript which then asynchronously loads 3 lines of CSS. So we went from a blocking call and 5 lines of code to 17 lines and an async call. How is this in any way better than simply cramming the 4 lines of CSS internally? Maintenance will not be simpler beca…
Because small doesn't mean 4 lines, they just used 4 lines for the example. Think of this like a "Hello World" for inlining CSS.
Earlier quoted context omitted.
Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...
What potential security vulnerability do inline styles have?
The same argument applies for CSS. If an attacker manages to output arbitrary HTML on your web page via some bug, they can add their own login form with " rel="nofollow">https://attacker/"> and harvest passwords this way. So CSP blocks that too. Again, this isn't because writing a form that way is a security vulnerability, but because if you've opted into CSP, you're stating that you're not writing forms this way so that you can enable these XSS and clickjacking protections.
It would be better to do the following:
1. Have only one or two external CSS files per page.
2. Serve CSS compressed when possible.
3. Ensure that CSS does not require any server-side processing or compression, that the server just spits out a .css or .css.gz file when the CSS is requested.
4. Ensure that the CSS files are relatively small.
5. Serve the CSS files with a very long cache time and with a version/hash string in the object name.
6. If feasible, make CSS changes relatively relatively rare.
If you do all of these things, adding the style into the web page will clutter your HTML and slow things down for frequent visitors. Yes, it might also increase perceived performance for some users who have not visited the site since the last change to the CSS.
Earlier quoted context omitted.
Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...
What potential security vulnerability do inline styles have?
(JS execution is mostly possible in obsolete browser versions though)