ExtendScript Toolkit

Adobe Scripting: collaborative code sharing

Davide Barranca —  — 24 Comments

An open letter to fellow devs

If you’re involved building third party solution for Adobe applications (mainly Scripts/Extensions) and you care about it, please invest 10 minutes of your time, read along and chime in.

Hi, I’m Davide

I’ve started scripting Adobe apps (mainly PS) back in 2008, with no prior programming experience whatsoever. I work full time as a post-production freelance since the year 2000, so my main focus can’t be on coding; yet over the years I’ve learned, mostly from others in public forums, enough to start a small paid scripts/extensions business that so far has been contributing for about 1:5 on average to my total incomes.

As a senior PS professional I can’t consider myself but as an amateur coder, yet I’m very passionate (isn’t passion what amateurs are about, after all?!)

What follows are my own and personal thoughts, that I’ve shared privately with some folks in the industry: nobody put me down (on the contrary, they strangely seemed to sustain my point of view!) so I’ve decided to eventually write this one publicly.

The Scripting communities

I can’t speak but about PS people; yet I’ve been in touch with many InDesign coders lately – from whom I got the personal, possibly incorrect impression that their community is stronger: in terms of available resources produced (forum threads, free and paid products, documentation), vitality, and, well, collaboration and sense of community. As a result I got the personal, possibly incorrect impression that they have more influence on Adobe as a software company.

Mind you, developers (no matter whether PS-ID-IL-AE-centric) understand they are just a tiny fraction of the company’s users base and it’s not from them the cash flow comes – hence their needs aren’t top priority, so to speak. We know.

The Photoshop scripting community, and by scripting I mean basically everything in the extensibility layer but C/C++ plugins (ExtendScript and Flash/HTML Panels, Generator/Node.js) do have some essential and well known keystones: preferences may vary, but I confidently list first the independent ps-scripts.com forum moderated by Mike Hall, which is where Ross Huitt (aka XBytor) has been sharing his great XTools and many skilled and very talented people constantly keep contributing. The official PS Scripting forum by Adobe (where in my opinion the signal/noise ratio is a bit lower). And lots of other personal websites devoted to PS scripting: Adobe’s Jeffrey Tranberry, Russell Preston Brown (aka. Dr. Brown), Tom Krcha, David Deraedt; Paul RiggottMichel MarianiTrevor Morris, John J. McAssey and many others  – I try to do my little part too.

Bad times?

Undoubtedly the PS Scripting community is undergoing some change. Paul Riggott, among the most skilled and helpful contributors, left forums altogether in protest with Adobe. XBytor declared to be burned out and not willing to start any major new project. In an official forum’s thread called “Will scripting be supported in future?” (worth reading too) John McAssey collected bits of different posts showing (some influent) community members’ bad mood – so to speak.

Private conversations I’ve had with people in this business confirmed that, generally speaking, there’s a lot of disaffection going on among developers: recent technologies Adobe rolls out of its hat are promising (HTML Extensions, Generator/Node.js) yet the past has taught us not to embrace them too enthusiastically nor too soon, because they might end unsupported in the mid-term. In a dog-chasing-its-tail loop that could even accelerate the process: take as an example Kevin Goldsmith‘s PixelBender, which never left the Labs and drop discontinued. Was that because Adobe judged the coders’ involvement too low to justify the development cost (as it’s been declared) or are the developers, who weren’t embracing the technology because Adobe didn’t put enough resources on it in order to make it really profitable? That was well before the Flash thing, which is by the way going to put an end to Flex Panels and Configurator very soon.

True, IT world is constantly moving on, but as someone who’s learned ActionScript from scratch “just” to code Flex panels back in CS4, I now approach HTML Panels in CC (three generations afterwards) and Generator with a tad of cold blood – I’m working full-time, married, in my late thirties and time is not exactly what I’m plenty of.

Cahiers de doléances

Bear with me and let me express some personal criticism before getting into some more pro-active, constructive comments. Here are my own Cahiers de doléances, provided that I assume engineers don’t like not to fix bugs, nor avoid implementing new features just to liven up the otherwise boring life of the third party developer – it’s management that decides where to put (or not to put) development resources.

  1. Scripting as we know it (i.e. ExtendScript) needs some love. It’s a language with its own true gems – as pointed out by the ID developer Marc Autret (who proved to be among the finest scripting connoisseurs): the JSXBIN compiler, File/Folder management, Reflection and Dictionary interfaces, Debugging/tracking services, preprocessor directives, native XML support, etc. – and some nightmares.
    Now that scripters are supposed to interbreed with web-devs for HTML panels (running on a Google Chromium implementation / V8 engine) at least in the long run the way data is passed/evaluated by the two engines should be unified – and ExtendScript upgraded to latest ECMAScript standards without losing its peculiarities.
  2. ScriptUI is a mess. Hopefully the switch to an HTML adapter that Tom Ruark’s envisioned will end up fixing the undisguised rendering differences and behavior discrepancies we’re drowning into now: inter-app (PS/ID/IL etc.), inter-platform (PS Mac/Win), inter-version (PS CSx/CC), it’s a minefield. I’ve been told that while ExtendScript specs are the Standard to refer to, each app’s team (PS/ID/IL/…) deals with its implementation independently: as a result, the consistency one would expect for a set of applications formerly knows as Creative Suite vanishes.
  3. ESTK (ExtendScript ToolKit) is… rather raw as an IDE for 2014 standards, suffers from many (old) bugs, code hinting is often inaccurate, it doesn’t provide any ScriptUI visual tooling, not to mention the fact its own ScriptUI implementation differs from all the other apps’ (aspect/behavior) implementation, which makes the whole thing quite pointless, and sometimes dangerous.
  4. PS scripting would greatly benefit from the implementation of some kind of Image Processing language available through scripting. It’s quite paradoxical that HTML Canvas element + JS (that is: HTML Panels!) can do image processing yet there’s no straightforward way to pass back and forth the open Document’s BitmapData. As far as I know, one could even port Processing code that way – wouldn’t that be just awesome?
  5. ActionManager code and the ScriptingListener plugin are a godsend, but first: there are many useful things beyond the AM reach, second: AM isn’t an excuse not to extend the DOM support anymore.
  6. HTML Panels are a wise move in the long run for sure – provided their implementation will overcome several teething problems and lack of documentation (I’m among the ones who remember the amazing series of articles written by the great Olav Kvern on CS SDK). Which is OK to deal with, unless the deadline for the Flex panels support in PS is Mid 2014 (that is: tomorrow morning, so to speak).
    Extensions cannot replace scripted windows (that are action recordable for instance), but are interfaces to, and evaluates, “traditional” scripting.

Others might have a different list of doléances, the above ones are just my favorite refrain.

Call for (some) action!

Notwithstanding, the PS scripting community is doing some interesting stuff and is spread over the internet under many forms. Yet all the available resources I’ve mentioned earlier, while undoubtedly valuable, appears very sparse. They’re able to answer to the question: “How do I…?” with snippets and explanation or just exposing source code, but mostly it’s just a matter of personal efforts. Disconnected from other personal efforts – by someone else – and for that reason less effective from the educational point of view.

Forums somehow fill the gap: it’s where you go asking questions and interacting with people, who are either likely to have run into your problem, or just more experienced to suggest a solution. Forums are an excellent archive, collecting the community’s accumulated knowledge, providing historically sorted references and discussions.

Yet, as a code repository, Forums cannot beat other tools that have been specifically designed to be exactly that: code repositories.

I have nothing revolutionary to propose: I’ve noticed how people involved in PS coding are sometimes very talented but either isolated, or interacting in ways that could be more profitable for the whole community – specifically for those who are not yet in the number, but will enter the community in the future: willing to learn and to make use of our accumulated knowledge.

Open Source Code Repositories

Over the years I’ve collected tons of Scripting related material, and you’re likely to have done the very same thing yourself.

Why don’t we create a set of collaboratively maintained, open sourced GitHub repositories, to store:

  • Snippets (functions, AM code, etc).
  • Boilerplate code.
  • Demo code and Tutorials/HOWTOs.
  • Libraries and Frameworks.
  • Links to notable Forum Threads, valuable external resources, etc.
  • Official and Unofficial Documentation.
  • Community’s feature requests.
  • You name it.

I have no intention to create the umpteenth PS-website, nor to substitute Forums (which keep being the best place for discussion to happen and ideas to be shared): I’d like to have a place to go to when I’m in need to borrow or learn code from (a-ehm, what Adobe’s DevNet should have been). I’m not exactly the smartest Git user in town, but I know that GitHub repos:

  1. Are forkable (you can clone it locally).
  2. There is a group of maintainers who is in charge of the not obvious problem of their design/structure.
  3. Allow Pull requests: that is, you can submit your own tweaks in order to have them integrated into the main line of development.
  4. Can contain not only sheer code but HTML/markdown documents – i.e. all sort of Documentation, Tutorials, etc.
  5. Provide collaborative coding tools such as Wiki, Issues tracking, etc.
  6. Are free and open source – you give bits of your time and knowledge for the whole community’s benefit.
  7. Can scale easily to include other apps (ID/IL/AE/…)
  8. Because they have been designed as a repositories, code there is version tracked and can be maintained more effectively (compared to Forums, where not very often old threads get revamped).

Chime in!

When I’ve happened to code commercial scripts I’ve tried to build tools that I would have liked to use myself – and this is the spirit I’m asking you for support with.

Looks like a complex thing to build from the ground up, yet it would help not only ourselves but those approaching scripting in the future too (and it doesn’t need to be built overnight); not to mention the fact that there could be a tiny chance this might strengthen the Devs Community to Adobe’s eyes – I don’t want to create a lobby, nor find a place to fill with narcissism: I’m a happy sociopath who lives in the countryside. I would like to consider Adobe Scripting a nice and profitable platform to develop for in the next, say, 5 years. To date, I’m not sure I would, frankly.

I’m still in a phase where I’m evaluating whether this project can arouse other people’s interest – it can’t be but a collaborative effort – or not (in case I’ll easily turn it into a personal hobby). I’m skating over the next big problem on the list, i.e. the design of such repository.

Would you like to chime in? Do you have any idea, feedback, suggestion along these lines? Can you provide GitHub/social coding experience and skills? Just want to high five and disappear? The comment section below is for you.

Thank you for your time,

Davide

Print Friendly
Share

24 responses to Adobe Scripting: collaborative code sharing

  1. Hi Davide,

    It’s nice someone says loud what many thinks silently. Regarding to the end of flash based extensions support, I am really sad. I was so excited when they came in that I really promoted them and made some really great stuff and business with them. And now, I am just taken my favourite toy out of my hands…
    How understandable the switch to HTML based extensions could be, I am a bit annoyed by how quick Adobe can run something and take it back without any warning. My main concern is the trust we can have in technologies. Are they worth the investment ? Yeah HTML5 based extensions…but for how long ? This lack of stability is a great concern to me.
    I really love adobe, their creativity and their products but it’s too risky for a business to only work with technologies you don’t know if there will still be there the next week. As a matter of fact, I have started working with another editors to reduce my dependancy to Adobe. It’s not an angry reaction, it’s just a precaution !
    I will keep on working with Adobe products for sure but obviously I am more and more careful now with implied technologies 😉
    And finally, your repos idea is fine. I will look forward to chiming in 😉

  2. Hi Davide,

    Would be happy to be part of that GitHub repository project. I feel like I’ve much to learn from social coding, so please put me on your list of wannabe contributors 😉

    Best,
    Marc

  3. Thiyagarajan (Green4ever in Adobe Forums) December 9, 2013 at 1:29 PM

    Hi Davide,

    I’m am not a great scripter/programmer, but I have decent experience in developing scripts for ID/PS/IL over 4+ years. I am sure that you are alone on this boat. Many peoples are looking to create/have this kind of source, including myself.

    I can contribute to this initiative as much as I can.

    Best Wishes
    ~Green4ever
    (Thiyagarajan)

  4. Thanks; Davide. I’m not a coder, but I understand that those in my case depend on the coder’s work. Anything that could help you craft the wonders we rely upon is a gift for the whose user community as well!

    Here’s hoping that your project will be fruitful!

    Is your request to unify the many exiting githubs? With a search for “Photoshop” or “Illustrator”; we see lots of projects on github!

  5. Davide, great article. As you might all ready know, I’ve been involved in the PS scripting community and share many of your concerns. We do need to support each other, as the documentation is so poor that we often need help figuring out how things really work. After working with extendscript since version CS, I still feel I’m a novice compared to many others, but would be happy to throw what I know into the mix.

  6. Hi Davide

    I agree community should left the adobe forums to other more intelligent and productive solutions.

    But in my case, I code for a team (photoshop/bridge), like you I code for a team of users and I’m not a professional coder (I’m a photo editor).
    I’m really concerned about the continuity of my work in the future.
    I have reached major successes, we have our own built crop grid, centralized studio color camera profiles, XMP central field info with company xmp namespaces, daily automatic actualization of scripts, accessory images, warnings by local language for English/portuguese collaborators, etc, etc.

    Much, much work that could be vanished if we are forced to go CC.

    And also so much to create and develop.

    My problem is that I’m not a GIT user and it seams a bit confusing for me.
    And also because my main work is photo editing and only sometimes coding.
    This means that I can ‘I five’ now and only collaborate only some times.
    That’s the reality.

    What you are proposing is only 50% of my concerns regarding coding. The other 50% is to convince my company investing more and more on coding for the team and present them results (which I have having now more time to code).

    For a middle-self-made-programmer, is there any tutorial on how to help more efficiently the community? On GitHub or not.

    I have a present project in mind that I would like to develop:
    – Detection of wrong calibration on multi photo studios by camera/light studio detection from XMP of the raw images and comparing with an xml data with the company default calibration (focal distance, ISO, aperture, etc). This would avoid repetitions on photographing in studios and avoiding lots of wasted time.

    Adobe, canon, don’t respond to this. And there aren’t really any solutions for a centralized multi-studio workflow and multi editing team workflow.
    On my workflow avoiding one click on every image is a major important issue.

    Adobe only is concerned about quality clients and not on productivity clients.

    And ‘productivity clients’ also have quality concerns. Productivity clients many times don’t even have discovered what scripts could done for them. And this have a disastrous result on the lack of pressure on ADOBE to develop this for them. Client can ask what he can see!
    And that is what I am doing but it is so difficult.

    Your idea would be an open road.

  7. Royston Marshall December 9, 2013 at 6:55 PM

    Great article. I didn’t know about the move to HTML extensions, but will look into this as (although very powerful) I never really liked the feel of flash based plugins.
    I would definitely be interested to be kept informed on this project, as a contributor, and consumer. I do know that I am not up there on the same level as most, but would willingly share any little tricks and tips I stumble upon.
    Great post!
    Roy.

  8. The forum community has been great to me. I am also frustrated with many of the changes that have been made since CS6. I am glad that you used your voice.

  9. I hear you, I agree with you, and I applaud your efforts. I’m in.

    I believe the problem is because we “Technical Artists” are a small group. Most often: Programmers become developers, Creatives become users. People on the edge between these worlds are a valuable but often overlooked resource. The past volatility of this environment means I couldn’t count on a tool lasting more than a couple years. But now CC’s constant updates are like trying to hit a moving target. It is scary, but as of a year ago, I’m fully invested. (read: I quit my job to create custom scripts and extensions full time.)

    By banding together we strengthen our community, create more awareness, and let the world see what kind of solutions are possible. Adobe could also see the amazing things that we are trying, doing, and achieving. They know we’re out here. We’re just so scattered and all hidden in our little corners.

    A repository is fine, but it has to be organized and easily searchable. Github can be a bit technical. What about a repository as part of PS-Scripts? Or cloud based solution that’s not as intimidating as Github can be?

    Pedro Marques:
    “Adobe only is concerned about quality clients and not on productivity clients.”
    YES! I agree with your statements whole heartily. My small business is built on the idea that productive creatives are better creatives. But getting the word out there so that people KNOW what can be done is the problem.

    Please keep this spirit alive. And let me know how I can help.

  10. @ Sandra

    > Github can be a bit technical. What about a repository as part of PS-Scripts?
    > Or cloud based solution that’s not as intimidating as Github can be?

    As far as I understand Davide’s aim PS scripting would just be a ‘branch’ of his project, since there are—anyway—many common fields at a higher (lower?) level, namely ExtendScript, ScriptUI, ESTK, HTML5, as mentioned in the Cahiers de doléances.

    Also, GitHub shouldn’t intimidate “Technical Artists” that much. In our scope, Fabian Morón Zirfas (aka fabiantheblind) has shown that very clean wiki-based resources can be maintained on such a platform: https://github.com/fabiantheblind/extendscript/wiki

    Marc

  11. Hey David,

    Nice article! I’ve done a lot of of ExtendScript in the last year while building Hyle, an After Effects script. You’ve wrote a little about me and the After Effects Scripting Sublime Text 2 Package your adapted for Photoshop.

    Anyways, I just wanted to tell you that, while building Hyle, I have also been working on a library/framework of actions and modules. Just as jQuery does for the web. It is not ready yet but it will probably be in a couple of months. It will be release as open source on Github and collaborations will be encouraged.

    Until then, Fabian does some pretty good job at releasing/documenting stuff.

  12. Hello Davide,

    I’m Fabian (aka fabiantheblind), mostly ID & AE scripter, heavy github user and I’m totally with you. We need a place were we can exchange code and collaborate. Github is the right place (IMO).
    so let’s do it. It is pretty easy to create a github organization what the hard thing is, is finding admins for that. Are you with me there?

    How should it be named? It should not conflict with the real adobe organization ( https://github.com/adobe ).

    First thing we should do when we have a name is make a repo with a wiki and create guidelines how to manage all that.

    I would suggest to users to create first the repos under their own account and later on we make a fork to the orga. This would help to not clutter the organization with to many unfinished projects.

    Minimum requirements to fork a repo to the orga could be like this:
    – README.md (with install and usage guidelines)
    – LICENSE
    – if useful a small gif animation

    It also needs some GitHub pages as a location to point to from other sites.

    We already created a small AE scripting orga ( https://github.com/ae-scripting ) but we could transfer some of the repos over to the new orga.

    So first thing. A name. Then we could take this over to github. Maybe discuss using issues.

    Best regards

    Fabian

  13. Davide
    Well said… in a large “nutshell” you’ve described my frustration with trying to learn PS Scripting of ANY sort over the last 18 years of the 21 years of using PS.
    I was thrilled when John Nack got the Configurator program going, and while it helped me with some things, it fell quite short for others. Scriptinglistner helps somewhat but is quite tedious to wade through for someone who is not a coder/programmer.
    Scripts that you and Giuliana have created really showed what I was trying to achieve(and still) am.
    But as you have already stated the constantly evolving and morphing of what is going to persist in PS makes it impossible for me to understand and happily jump into as I have with PS.
    Thanks for your efforts and continued willingness to share and improve the PS community.
    Chris

  14. Hey Community… here is a thought…
    What about that same Github community also being a center point for job posting and talent seeking?

    There are times I have been just swamped. I wished I could find an experienced adobe developer types to contract on for a job. But supply and demand are against me! 1. Hard to find folks with the limited supply. 2. Everyone I do find is busy!

    So… might be nice if when those moments come up, if there was place we could go to find experienced folks, such as yourselves, and post paying gigs.

    For example, I often get jobs that are often cross application. Because of the differences between apps ( ID, PS, AE, and AI) – it might be nice to give the ID part to the ID guy, the AI part to the AI guy.etc .. (and be a master at BridgeTalk.).

    Thoughts?

  15. Hello everybody,
    first a big thank you for the warm response!
    I’m currently on a holiday rush at work, but I’m reading each and every comment you’re posting – it looks like I’ve hit a nerve.
    I’d like to let you people express freely on the topic, then we can collect some of the good ideas you’ve been sharing and put them in practice, with the help of those who already have an “open source” approach.
    Thanks again for all the comments, retweet, posts, etc – your support is very much appreciated!
    Davide

  16. Hi Davide,

    You’re voicing the concerns that we seem to all have. I hope someone in Adobe management will see this and take notice. I’ve actually thought about putting together an open letter to Adobe management to express the concerns that we’re feeling in an organized manner.

    A few years ago, I was planning on putting together a community on my website: http://in-tools.com/learning/forum/ I even created a private forum only visible to developers for discussing topics that are best left out of public eye. Of course I got busy with other things, and nothing came of it…

    In the meanwhile, a few of us got together to form UnHurdle http://unhurdle.com/ We’re hoping that a major focus of UnHurdle will be bridging the gap between developers and users as well as supporting developers’ needs. The initial release of the (free) Resource Panel is our first step towards that goal.

    The Creative Developer Community is quite unique in that although there might be some competition, I have not encountered any hostility. Quite the opposite. People are very helpful to one another. I think it’s ripe for building that community further.

    I’m not sure exactly what I’m saying here other than rambling, but I am all for your initiative, and I think we all need each other for our community to thrive.

    One idea might be hosting a forum on UnHurdle similar to what I wanted to do on In-Tools.com. I think UnHurdle is a much better place for that anyway…

    @Sandra I agree wholeheartedly, and that was part of my idea of the closed forums. It could be a place to discuss job opportunities and work collaboratively.

  17. In a on-line community of scripters, I would suggest a clear sub-group distinction based on interests:

    subGroup 1: general common scripts users
    subGroup 21: photographers
    subGroup 22: publishers indesign/illustrator
    subGroup 3: corporate multi-script for teams or central scripts network

    (…)

  18. I would love to support it as well. Living with the revenue generated by Photoshop Extensions myself (I left a very stable job at Microsoft after 11 years just to focus on my product) I am pretty scary with the lack of support and the changing to HTML panels.

    Not that I like Flash panels but, my main concern is the fact I will need to have 2 different code bases for customers with CS5 and 6 and customers with CC – not a good thing for a small company like mine. Also, time is coming and no good documentation/examples on how to convert Flash to HTML panels (my panels are pretty complex) is available yet.

    Agree with others that Github is a bit intimidating.

    Anyways, lets see what we can do together.

  19. Since I’ve mentioned the Adobe Developer Connection (ADC), I think it’s worth linking this blogpost by Brian Rinaldi (Adobe Content and Community Manager in Developer Relations) who wrote:

    Back in February, Adobe made some changes internally, choosing to place most of the company’s focus on the Creative Cloud. This emphasis meant the end of some efforts, which included the Adobe Developer Connection.

    I’ve reached Brian via Twitter asking whether he meant that his contribution to the ADC was ending, or the ADC itself: he kindly answered that as a matter of fact there hasn’t been any new content added in 6 months or so, yet the website is kept online. I guess it’s a (understandable) way to unofficially confirm that we shouldn’t expect nothing from ADC in the future.

    Davide

    • GLenn Williams April 3, 2014 at 10:12 AM

      This is just the way its been going the last few years. Over the last couple of years Adobe have just dumped developers working with their tech. I wont develop against Adobe stacks ever again. No matter what they are. having invested in flash, flex, coldfusion, Livecycle, and Creative suite scripting both developing to those products and also selling on solutions based on those products to many clients and then having Adobe just change their focus away from developers has left me with a lot of problems.

      My advice, as much as I love adobe and their products, is as a developer just keep away. Don’t get involved in producing code against any Adobe SDK unless its for a hobby. Ive been too badly burned in the past.

      Its such a shame.

  20. Hi Davide,
    although I’m pretty new at scripting Adobe applications, I share all of your frustration. Thank you for writing this post.

    Over the last few months I’ve been developing scripts and a Flash-based plugin to improve my workflow within Photoshop (being a 3D Artist I mainly use it for texturing), but found the process incredibly daunting.

    Documentation is very limited and the only way I found to get started was through a lot of trial and error and some websites such as your blog, ps-scripts.com and others. Having no access to Extension Builder was a real pain too: I had to rely on free softwares (i.e. FlashDevelop) and community tools like “csxs” (a command line utility for NodeJS) and a growing set of self developed scripts and utilities to be able to make the process as straightforward as possible.

    As much of what I can do today is mostly based on what I learned through community-run websites and by using community tools, I would love to support your initiative.

  21. Hey Davide, I’d like to give you a high-5 for the initiative, I share your feelings as well as the others who have posted here, if I can be of any help, count me in. I script exclusively in Illustrator (the worst of the lot among the suite, but what can I say, I guess it is better than not having scripting capabilities).

    looking forward to seeing this project come alive

  22. High-5,

    I am primarily C++ plugin developer. I had to make what seemed to be simple thing, html panel that read from PS registry and call plugin. To me scripting Photoshop was a nightmare not because scripting is hard but for lack of tools, bugs in tools, lack of finding consistent information.

    Best wishes.

  23. I would also like to express my frustration too. Open source developers could help make Adobe products do amazingly cool things… But developing in its current state is so hard and frustrating. I feel like there is always too much concentration on pushing new services and selling new wing ding features that I rarely use (or if I do I used to do it from a script or plugin anyway) rather than spending time maintaining core functionality.

Leave a Reply

Text formatting is available via select .

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url=""> 

*
*