Tag Info

Hot answers tagged

50

No, this is not a good practice. You should use already semantic, meaningful tags -- perhaps <em> in this case -- and apply CSS styles to achieve your design requirements.


13

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 ...


8

Specific color schemes cannot be objectively better than all other color schemes, their ranking would be individually subjective based on taste and cultural factors. However, certain rules for readability / clarity, use in particular ambient light environments etc etc... are applicable, these would carry over from graphic design / typography, human computer ...


8

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: http://www.w3.org/Style/XSL/WhatIsXSL.html http://www.4guysfromrolla.com/webtech/081300-2.shtml http://www.ibm.com/developerworks/xml/library/x-tiphtml/index.html ...


7

Code Bubbles are neat. Microsoft has adapted the idea for debugging purposes in Debugger Canvas.


7

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 ...


5

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 ...


5

You could use <em /> and <strong /> with custom CSS to alter how it's displayed. Strong, refers to stronger importance. Emphasis, refers to increased emphasis.


4

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. ...


4

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 ...


4

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. ...


4

Take a look at JetBrain's Meta Programming Systems (MPS) project. One of its central points is the departure from plain-text representation of programs in favor of tree-like in-memory structures that represent the same concepts. The MPS editor lets you manipulate these trees with the simplicity of manipulating plain text representations, and build programs ...


4

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 ...


3

One issue is that different languages have different parsing requirements. It would be nice if all existing computer languages had nice LL(1) context-free grammars, but they don't. Some languages, like C and C++, cannot be parsed without input from other parts of the compiler. Also, before the parser comes lexical analysis, which divides input into ...


3

If you don't like SP's you can always use a View. So your SQL is stored in the DB. You can create an Entity in your ORM based on your view's data structure. See this link to the MySQL docs.


3

No, although it is allowed to add new tags from another namespace in XHTML, the processing of HTML tags which are not specified is strongly discouraged.


2

I don't think such studies exist. In practice, when a company creates a new IDE, the syntax highlighting color scheme is based on the existent schemes of other IDEs. For example, the default Visual Studio theme has nothing new nor original. Blue color was used for keywords for years, including by old Ada IDEs. Same thing for green comments. Some colors were ...


2

This post from a couple years ago when they first added syntax highlighting says that they'll add other languages by request. We plan to add more languages based on your requests. Please create an issue in the CodePlex Issue Tracker to request syntax highlighting for additional languages, or to report any problems you find with the current languages. I ...


2

First off all non-trivial applications have issues with ORM. They are great for CRUD operations but beyond that they just don't work. This isn't a unique problem to your situation. Don't let anyone tell you that you are doing something wrong by running up on the limits of whatever ORM you are using, they all suck at something, most of the times performance ...


2

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.


2

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 ...


2

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 ...


1

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. ...


1

In "view source", you see the original source downloaded. What you'd get with wget or lynx for example. The end result you see has been manipulated by Google Code Prettify's JavaScript code, and can be seen with tools such as Chrome Dev Tools or Firefox Dev Tools. As Servy said, the DOM is riddled with <span> tags and the likes.


1

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 ...


1

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 ...


1

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.


1

For those cases I normally create a stored procedure, in great part because what you just mentioned - I have the database to check syntax and I can use its tools to edit it, and I can also test it.


1

http://www.w3.org/TR/html5/elements.html 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.


1

No you can't create your own HTML tags, because you would then have to get all major browsers to implement them, currently when browsers find an unrecognized tag they ignore everything in it, so unless you want to make your own browser creating a new tag is pointless, and even then they would only work in your browser. You could try submitting a use-case ...



Only top voted, non community-wiki answers of a minimum length are eligible