Related
I just upgraded to Sublime Text 3.
I'm using my existing Color scheme from Sublime Text 2. But now multi language code highlighting no longer works.
Sublime Text 3
Sublime Text 2
Can someone help me comeup with the custom scope for my tmTheme.
Congratulations on upgrading, it was a good choice. I'm using ST3 Build 3120, the latest development build, so the language definitions may have changed somewhat, but not significantly, if you're using the public beta Build 3114. I also use the Neon Color Scheme (full disclosure: I'm the developer), which has a very large number of specific scopes compared to some other color schemes like Monokai or Solarized which reuse the same colors for a variety of different language features. Finally, since I'm a color scheme designer, I use tools like ScopeHunter and ScopeAlways to determine which scopes and theming elements are active at any point in the text.
So, here's a screencap of your code plus a couple of other test lines using Sublime's HTML syntax:
and here is the same code, moments later, captured using the PHP syntax:
What we can see is that, in the lower left corner, ScopeAlways is indicating that, at the position of the cursor, the base scope of the HTML file is text.html.basic, while the PHP one is embedding.php text.html.basic. So far, so good - this is normal. More importantly, however, we can see the obvious difference in highlighting between HTML and PHP, including the contents of the id attribute as compared to the other attributes, and the coloring (or lack thereof) of the embedded PHP code (yes, I know I'm missing a ; at the end of the isolated PHP code at the bottom - adding one in doesn't change anything).
So, my first suggestion would be, if you're not already using it, is to set the syntax of the file to PHP. You can either select from the menu on the far right side of the bottom bar, or by selecting View → Syntax → and choosing from the options available.
If you're already using the PHP syntax, you should know that since the beginning of this year (more or less), many of Sublime's language description syntax files have been significantly or completely rewritten, PHP and HTML among them. They were in sore need of modernization and speed-up in some cases, and with the advent of the sublime-syntax format (much more powerful than the old, but still supported, tmLanguage format), a better regex engine for .sublime-syntax files, and the hiring by Sublime HQ of Will Bond (of Package Control fame) to do a lot of things that Jon Skinner (Sublime's author) didn't have time or interest in doing, the development process of both Sublime itself as well as the syntax definitions (which were open-sourced at the same time) has increased substantially. That is a really long-winded way of saying that a lot of stuff has changed in a relatively short amount of time, and color schemes that were written with the old versions of the HTML and PHP syntaxes in mind may not be perfect for the new versions. So, you may want to either go through the new syntaxes and update your color scheme, if you're that kind of person, or you can try some other schemes like Neon, which have already been through that process.
Getting back to that weird id highlighting - I'm going to release a new version of Neon fairly soon that fixes that issue, and colors the contents of the id attribute just like class or any other attribute. I'll also try and find out why they did that.
I hope this helps. Good luck!
Could anyone give me a good use case for ActionScript dynamic classes?
Because it really looks like a bad pratice, for me, in every case.
Anything that uses Proxy must by extension be dynamic. I use Proxy fairly regularly; for example, here's a replacement syntax for ExternalInterface using Proxy.
URLVariables, for example.
You could store the data in a dictionary / object / array too, but you don't gain much in this case, I think, and you cut down some boilerplate.
Well you could use an Object object, but using a dynamic class ensures that it is typed. That's the way I see it, and it's the only reason I would use them. What Juan Pablo is saying is a good reason too.
I was wondering, and was as of yet, unable to find any answers online, how to accomplish the following.
Let's say I have a string that contains the following:
my_string = "Hello, I am a string."
(in the preview window I see that this is actually formatting in BOLD and ITALIC instead of showing the "strong" and "i" tags)
Now, I would like to make this secure, using the html_escape() (or h()) method/function.
So I'd like to prevent users from inserting any javascript and/or stylesheets, however, I do still want to have the word "Hello" shown in bold, and the word "string" shown in italic.
As far as I can see, the h() method does not take any additional arguments, other than the piece of text itself.
Is there a way to escape only certain html tags, instead of all? Like either White or Black listing tags?
Example of what this might look like, of what I'm trying to say would be:
h(my_string, :except => [:strong, :i]) # => so basically, escape everything, but leave "strong" and "i" tags alone, do not escape these.
Is there any method or way I could accomplish this?
Thanks in advance!
Excluding specific tags is actually pretty hard problem. Especially the script tag can be inserted in very many different ways - detecting them all is very tricky.
If at all possible, don't implement this yourself.
Use the white list plugin or a modified version of it . It's superp!
You can have a look Sanitize as well(Seems better, never tried it though).
Have you considered using RedCloth or BlueCloth instead of actually allowing HTML? These methods provide quite a bit of formatting options and manage parsing for you.
Edit 1: I found this message when browsing around for how to remove HTML using RedCloth, might be of some use. Also, this page shows you how version 2.0.5 allows you to remove HTML. Can't seem to find any newer information, but a forum post found a vulnerability. Hopefully it has been fixed since that was from 2006, but I can't seem to find a RedCloth manual or documentation...
I would second Sanitize for removing HTML tags. It works really well. It removes everything by default and you can specify a whitelist for tags you want to allow.
Preventing XSS attacks is serious business, follow hrnt's and consider that there is probably an order of magnitude more exploits than that possible due to obscure browser quirks. Although html_escape will lock things down pretty tightly, I think it's a mistake to use anything homegrown for this type of thing. You simply need more eyeballs and peer review for any kind of robustness guarantee.
I'm the in the process of evaluating sanitize vs XssTerminate at the moment. I prefer the xss_terminate approach for it's robustness—scrubbing at the model level will be quite reliable in a regular Rails app where all user input goes through ActiveRecord, but Nokogiri and specifically Loofah seem to be a little more peformant, more actively maintained, and definitely more flexible and Ruby-ish.
Update I've just implemented a fork of ActsAsTextiled called ActsAsSanitiled that uses Santize (which has recently been updated to use nokogiri by the way) to guarantee safety and well-formedness of the RedCloth output, all without needing any helpers in your templates.
I know that is the reason some people don't approve of them, but does it really matter? I think that the power that they provide, in interacting with JavaScript and storing and sending information from and to the server, outweighs the validation concern. Am I missing something? What are the ramifications of "invalid" HTML? And wouldn't a custom DTD resolve them anyway?
The ramification is that w3c comes along in 2, 5, 10 years and creates an attribute with the same name. Now your page is broken.
HTML5 is going to provide a data attribute type for legal custom attributes (like data-myattr="foo") so maybe you could start using that now and be reasonably safe from future name collisions.
Finally, you may be overlooking that custom logic is the rational behind the class attribute. Although it is generally thought of as a style attribute it is in reality a legal way to set custom meta-properties on an element. Unfortunately you are basically limited to boolean properties which is why HTML5 is adding the data prefix.
BTW, by "basically boolean" I mean in principle. In reality there is nothing to stop you using a seperator in your class name to define custom values as well as attributes.
class="document docId.56 permissions.RW"
Yes you can legally add custom attributes by using "data".
For example:
<div id="testDiv" data-myData="just testing"></div>
After that, just use the latest version of jquery to do something like:
alert($('#testDiv').data('myData'))
or to set a data attribute:
$('#testDiv').data('myData', 'new custom data')
And since jQuery works in almost all browsers, you shouldn't have any problems ;)
update
data-myData may be converted to data-mydata in some browsers, as far as the javascript engine is concerned. Best to keep it lowercase all the way.
Validation is not an end in itself, but a tool to be used to help catch mistakes early, and reduce the number of mysterious rendering and behavioural issues that your web pages may face when used on multiple browser types.
Adding custom attributes will not affect either of these issues now, and unlikely to do so in the future, but because they don't validate, it means that when you come to assess the output of a validation of your page, you will need to carefully pick between the validation issues that matter, and the ones that don't. Each time you change your page and revalidate, you have to repeat this operation. If your page validates entirely then you get a nice green PASS message, and you can move on the next stage of testing, or to the next change that needs to be made.
I've seen people obsessed with validation doing far worse/weird things than using a simple custom attribute:
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
In my opinion, custom attributes really don't matter. As other say, it may be good to watch out for future additions of attributes in the standards. But now we have data-* attributes in HTML5, so we're saved.
What really matters is that you have properly nested tags, and properly quoted attribute values.
I even use custom tag names (those introduced by HTML5, like header, footer, etc), but these ones have problems in IE.
By the way, I often find ironically how all those validation zealots bow in front of Google's clever tricks, like iframe uploads.
Instead of using custom attributes, you can associate your HTML elements with the attributes using JSON:
var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };
And as for the ramifications, see SpliFF's answer.
Storing multiple values in the class attribute is not correct code encapsulation and just a convoluted hack way of doing things. Take a custom ad rotator for instance that uses jquery. It is much cleaner on the page to do
<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />
and let some simple jquery code do the work from here.
Any developer or web designer now can work on the ad rotator and change values to this when asked without much ado.
Coming back to project a year later or coming into a new one where the previous developer split and went to an island somewhere in the pacific can be hell trying to figure out intentions when code is written in an unclear encrypted manner like this:
<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes" />
When we write code in c# and other languages we don't write code putting all custom properties in one property as a space delimited string and end up having to parse that string every time we need to access or write to it. Think about the next person that will work on your code.
The thing with validation is that TODAY it may not matter, but you cannot know if it's going to matter tomorrow (and, by Murphy's law, it WILL matter tomorrow).
It's just better to choose a future-proof alternative. If they don't exist (they do in this particular case), the way to go is to invent a future proof alternative.
Using custom attributes is probably harmless, but still, why choose a potentially harmful solution just because you think (you can never be sure) it will cause no harm?. It might be worth to discuss this further if the future proof alternative was too costly or unwieldy, but this is certainly not the case.
Old discussion but nevertheless; in my opinion since html is a mark-up and not a progamming language, it should always be interpreted with leniency for mark-up 'errors'. A browser is perfectly able to do so. I don't think this will and should change ever. Therefore, the only important practical criteria is that your html will be displayed correctly by most browsers and will continue to do so in, say a few years. After that time, your html will probalbly be redesigned anyway.
Just to add my ingredient to the mix, validation is also important when you need to create content that can/could be post-processed using automated tools. If your content is valid you can much more easily convert markup from one format to another. For example, doing valid XHTML to XML with a specific schema is Much easier when parsing data that you know and can verify to follow a predictable format.
I, for example NEED my content to be valid XHTML because very often it is converted into XML for various jobs and then converted back without data loss or unexpected rendering results.
Well it depends on your client/boss/etc .. do they require it be validating XHTML?
Some people say there are a lot of workarounds - and depending on the sceneraio, they can work great. This includes adding classes, leveraging the rel attribute, and someone that has even written their own parser to extract JSON from HTML comments.
HTML5 provides a standard way to do this, prefix your custom attributes with "data-". I would recommend doing this now anyway, as there is a chance you may use an attribute that will be used down the track in standard XHTML.
Using non-standard HTML could make the browser render the page in "quirks mode", in which case some other parts of the page may render differently, and other things like positioning may be slightly different. Using a custom DTD may get around this, though.
Because they're not standard you have no idea what might happen, neither now, nor in the future. As others have said W3C might start using those same names in the future. But what's even more dangerous is that you don't know what the developers of "browser xxx" have done when they encounter they.
Maybe the page is rendered in quirks mode, maybe the page doesn't render at all on some obscure mobile browser, maybe the browser will leak memory, maybe a virus killer will choke on your page, etc, etc, etc.
I know that following the standards religiously might seem like snobbery. However once you have experienced problems due to not following them, you tend to stop thinking like that. However, then it's mostly too late, and you need to start your application from scratch with a different framework...
I think developers validate just to validate, but there is something to be said for the fact that it keeps markup clean. However, because every (exaggeration warning!) browser displays everything differently there really is no standard. We try to follow standards because it makes us feel like we at least have some direction. Some people argue that keeping code standard will prevent issues and conflicts in the future. My opinion: Screw that nobody implements standards correctly and fully today anyway, might as well assume all your code will fail eventually. If it works it works, use it, unless its messy or your just trying to ignore standards to stick it to W3C or something. I think its important to remember that standards are implemented very slowly, has the web changed all that much in 5 years. I'm sure anyone will have years of notice when they need to fix a potential conflict. No reason to plan for compatibility of standards in the future when you can't even rely on today's standards.
Oh I almost forgot, if your code doesn't validate 10 baby kittens will die. Are you a kitten killer?
Jquery .html(markup) doesn't work if markup is invalid.
Validation
You shouldn't need custom attributes to provide validation. A better approach would be to add validation based on fields actual task.
Assign meaning by using classes. I have classnames like:
date (Dates)
zip (Zip code)
area (Areas)
ssn (Social security number)
Example markup:
<input class="date" name="date" value="2011-08-09" />
Example javascript (with jQuery):
$('.date').validate(); // use your custom function/framework etc here.
If you need special validators for a certain or scenario you just invent new classes (or use selectors) for your
special case:
Example for checking if two passwords match:
<input id="password" />
<input id="password-confirm" />
if($('#password').val() != $('#password-confirm').val())
{
// do something if the passwords don't match
}
(This approach works quite seamless with both jQuery validation and the mvc .net framework and probably others too)
Bonus: You can assign multiple classes separated with a space class="ssn custom-one custom-two"
Sending information "from and to the server"
If you need to pass data back, use <input type="hidden" />. They work out of the box.
(Make sure you don't pass any sensitive data with hidden inputs since they can be modified by the user with almost no effort at all)
Is there a way to reassign or change the core namespaces of mediawiki? For example, I'm having difficulty linking to a page I want to call "Template" because mediawiki has a namespace already for Template. I'd like to re-assign the mediawiki "template" namespace to something else.
Any thoughts?
You can partly change the name, under localsettings.php, add extra namespaces with the code number of template like adding main as 0, main:Main Page will redirect to Main Page
Basically, no.
You can change the display names of the namespaces in Special:AllMessages, and you can make aliases for the namespaces with $wgNamespaceAliases, but I don't think you can actually change the underlying names.
For example, to go to the talk page for Stack Overflow on the german wikipedia you can use http://de.wikipedia.org/wiki/Talk:Stack_Overflow or http://de.wikipedia.org/wiki/Diskussion:Stack_Overflow and they both take you to the same place.
BUT: The english wikipedia there is a page called Template and I just tested by making a page called Template on my wiki with no problems. So maybe it isn't the template namespace interfering. When I made a link to Template on my wikipedia userpage with [[Template]] it linked to the article Template, not to the name space.
I would advise very strongly against changing the names of any standard namespace. A name like "template" is so generic that surely you can find something else. For instance if you want to store code for C++ templates, call the namespace "Cpp_template" or "template_code".
Nothing in mediawiki prevents you from just using a colon as a prefix in a name, giving you exactly the same syntax as "supported" namespaces. I use that often. If it becomes helpful to differentiate those namespaces, e.g. for searching, then yes you can support them by editing LocalSettings.php (get the capitalization right folks, it matters in English, Linux shells and mediawiki).
For instance if I want to mark out a term as potentially problematic or biased, I use a "term:" prefix, for things like "term:Make_America_Great_Again" or "term:MAGA" which means the exact opposite of what its proponents claim. If I want to mark out verb phrases used in a user interface, it's "verb:delete" etc. For most of these it's not actually necessary to "support" the namespace.
You should ruthlessly customize namespaces and (even more so) categories for your task and purposes. If you are copying categories from some other wiki, you are probably doing it wrong. If you have not created any custom namespaces at least in the informal way I suggest, you are again probably doing it wrong.
But renaming standard namespaces or pages is a bad idea. You can use redirects for some of the same purposes. For instance, some "Special" pages have confusing and semantically inappropriate names that don't fit Wikipedia's or English language conventions. So I always redirect things like "Special:Wantedpages" with a new name like "open_links_in_this_wiki" which is semantically exact and doesn't tell people to just go create "wanted" pages with garbage in them instead of waiting to figure out if the name is appropriate or converging.
As a general rule, if you can't use the name easily in an English language sentence and [[just put brackets around it]], you need a redirect or rename.