I feel it greatly eases the stress on my eyes after long hours of coding. 99% white screen on a bright monitor is asking for a headache.
I also find this very funny, as in web design class in college we were told "NEVER DO THAT" to a webpage ... yet most developers using computers for a long time use it.
Are we designing websites to not be used for long ...
Your question asked if it's "good practice or legal".
Firstly: it's sort-of legal - at least, it's tolerated. Browsers have always been programmed to cope with tags they don't understand, even if that means they just ignore them. This HTML code:
Some <b>bold</b> and some <slanted>italic</slanted>.
Will appear like this is every ...
I firmly believe that it's more good for the eyes. When I sit in front of a monitor for 12 hours constant stream of light(white screen) is really tiring while the dark color is not so intense.
Let me describe more of my setup. At home I use dual screen setup with dark themes and a lamp because I find my sensitive eyes work best when background is lit. ...
Text color is enough for that purpose. In most editors I've used, I can clearly see the comments, the keywords, the strings, etc. There is simply no need to visually complicate stuff with background color.
Another element is that backgrounds are used, but for the purposes other than syntax highlighting. For example, in Visual Studio:
Background colors are ...
There are quite a few answers here explaining why you should never create your own custom tags. Arguably, they are all incorrect.
WHATWG's analysis of custom tags concludes that they are acceptable, standards compliant (since the handling of unrecognized tags is well defined) and more accessible than, for instance, styling a generic div.
If you need to keep the semantics of <important/> for specific reasons, you can use XSL to transform your custom tags into valid HTML. You can read more on this topic here:
We recently did a user study on code presentations that are visually richer than syntax highlighting. While it is not quite a study on syntax highlighting schemes, you might find it insightful:
D. Asenov and O. Hilliges and P. Müller - The Effect of Richer Visualizations on Code Comprehension
and here is the video of the 10 minute talk at CHI 2016.
They only moderately recent study that is remotely related to the subject I know of is one from 2004: "The impact of web page text-background colour
combinations on readability, retention, aesthetics
and behavioural intention" by Hall & Hanna. However, it's not for the code but web pages and the only color scheme they consider is foreground and ...
I think its mostly a personal preference, very few people do extensive studies on their editor colorscheme.
Over the last decades I found people justifying it with one or more of the following reasons (among which some were used for black on white too)
They come from DOS or similar times, and it was like that always.
When they started coding, there was a ...
I'd typically vote against stored procs or views unless you've got a great database build and migration system in place -- it is just too easy to get things out of synch.
Insofar as how to store them in your code, typically I'd vote they travel with the appropriate classes that are touching the database and executing the SQL. I don't see any downside to ...
On the practical side, it is unnecessary to use new tags for highlighting. You can use em or i tags if you prefer italics as default (non-CSS) rendering and strong or b if you prefer bolding as default. If, for some reason, you prefer default rendering as normal text, i.e. no highlighting, use span. In each case, you can use a class attribute to distinguish ...
You're right so far. In all cases, you have to have a rigorous description of the syntax of the language (a "grammar") before you can build something that can take something allegedly in that language and determine if it complies with the syntax rules (a "parser").
The parser is the front end of a compiler. Code generation is the back end.
There are ...
This is revision 1.5612.
Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future.
Well, it's legal in that you aren't going to get arrested for doing it. But if assassins from the W3C show up at your door, don't be surprised.
First off, other devs aren't going to know what they mean. In the case of <important> and <highlight> they are, but if you use something like, say, <set>, you might know you're referring to a ...
We typically segregate DB-specific stuff into one or more Strategy classes, and then configure them at deployment time. I once over-engineered a solution that would auto-wire everything at run time after introspecting the database connection, but it was overkill for the trivial effort required for a one-time set-up procedure.
Unless there is some other requirement here, I don't see any need to ever return to the original 'undecorated' rope. The rope, based on your question, exists only in order to support these decorations. An undecorated rope is therefore a needless complication.
Instead what you need to do is have 2 (or more) routines for how you turn the tree into an output....
I honestly don't see the benefits. The human eye is much better at reading dark text on a bright background. Also, black on white color schemes work much better when you're in a brightly lit environment.
While the human eye is better at reading dark text on light background, that configuration is also more stressful on the eye. When you are looking into a ...
In "view source", you see the original source downloaded. What you'd get with wget or lynx for example.
As Servy said, the DOM is riddled with <span> tags and the likes.
If you're using version control and some kind of compare tool you should be able to easily see if someone changes any embedded sql when they check something in. And if something breaks you should also be able to easily find which checkin had the changed code. You may be able to establish some practice of putting sql in variables so it is all defined at the ...
Definitely the route to go here is stored procedures. You might be able to maintain discipline for a while with embedded SQL, but IMO this always breaks down eventually. All it takes is someone going in to modify something a year or two from now and leaving SQL injection vulnerabilities everywhere, which is particularly easy to do with embedded SQL.
Ignoring everyone elses opinion here.
It's not good practice for two very important reasons:
First, it is entirely possible that at some point the standards committee decides to include a tag named <important> that ends up wacking your use for it. Sure, it might take a while.. But its possible you are going to waste time ripping it out afterwards.
As a kind of rough study, the screenshots below show 3 color themes used to syntax highlight XSLT. I've chosen XSLT as it poses a particular challenge because of the large number of language elements - and also because many developers describe it as ugly.
The number of colors used in the sample helps ...