Related
I have a site that wraps some user-generated content, and I want to be able to separate the markup for the layout, and the markup from the user-generated content, so the u-g content can't break the site layout.
The user-generated content is trusted, as it is coming from a known group of users on my network, but nonetheless only a small subset of html tags are allowed (p, ul/ol/li, em, strong, and a couple more). However, the user-generated content is not guaranteed to be well-formed, and we have had some instances of malformed user-generated content breaking the layout of the site.
We are working with our users to keep the content well-formed, but in the meantime I am trying to find a good way to separate the content from the layout. I have been looking into namespaces, but have been unable to find good documentation about CSS support for embedded namespaces.
Anyone have any good ideas?
EDIT
I have seen some really good suggestions here, but I should probably clarify that I have absolutely no control over the input mechanism that the users use. They are entering content into one system, and my page uses that system's API to pull content out of it. That system is using TinyMCE, but like I said, we are still getting some malformed content.
Why not use markdown
If your users are HTML literate or people that can grasp the concept of markdown syntax I suggest you rather go with that. Stackoverflow works great with it. I can't imagine having a usual rich editor on Stackoverflow. Markdown editors are much simpler and faster to use and provide enough formatting capabilities for most situations. If you need some special additional features you can always add those in but for starters oute of the box capabilities will suffice.
Real-time view for self validation
But don't forget to include a real time view of what users are writing. Self validation makes miracles so they correct their own mistakes before posting data.
Instead of parsing the result or forcing the user to use a structured format, just display the content within an iframe:
<iframe id="user_html"></iframe>
<script>
document.getElementById("user_html").src = "data:text/html;charset=utf-8," + escape(content);
</script>
I built custom CMS systems exclusively for several years and always had great luck with a combination of a quality WYSIWYG, strong front-end validation, and relentless back-end validation.
I always gravitate toward CKEditor because it's the only front-end editor that can deal with Microsoft Word output on the front end...that's a must-have in my books. Sure, others have a paste from word solution, but good luck getting users to use it. I've actually had a client overload a db insert thanks to Microsoft Word that didn't get scrubbed in Tiny. HTML tidy is a great solution to clean things up prior to validation on the back end.
CK has built-in templates and classes, so I used those to help my users format without going overboard. On the back-end I checked to ensure they hadn't tried any funny business with CSS, but it was never a concern with that group of users. Give them enough (safe) features and they'll never HAVE to go rogue.
Maybe overkill, but HTML
Tidy
could help if you can use it.
Use a WYSIWYG like
TinyMCE
or CKEditor that has built in cleanup methods.
Robert Koritnik's suggestion to use markdown seems brilliant, especially considering that you only allow a few harmless formatting tags.
I don't think there's anything you can do with CSS to stop layouts from breaking due to open HTML tags, so I would probably forget that idea.
It seems the most common aproach to web design is to use HTML/XHTML & CSS in conjunction with other technologies or languages like Javascript or PHP.
On a theoretical level, I'm interested to know what other languages or technologies could be used to build an entire site without using a single HTML tag or CSS style for styling/positioning?
Could a website be made only using XML or PHP alone, including actual styling and positioning?
Presumably Flash sites are till embedded in HTML tags?
Thanks
There are actually several solutions that allow you to nearly completely avoid CSS and HTML.
GWT: Google Web Toolkit
Written in Java and will allow you to build both server and client code in Java. Used to build Google Wave.
Cappuccino and Objective-J:
Objective-J is to JavaScript as Objective-C is to C. It extends JavaScript with many near features, including type-checking, classes and types.
Cappuccino is like Cacoa (Mac OS X GUI toolkit).
Using these two you can build incredibly rich and desktop like webapps. They run mostly on the client side and you can use whatever you want on the server.
A good example is 280slides
SproutCore is similar to Cappuccino, but it uses pure JavaScript instead. Apple is using SproutCore to make me.com.
I should also mention that knowledge to HTML, CSS, JavaScript is a good skill to know, just like understanding your compiler is a good skill.
EDIT:
As said above Adobe Flash can also be used.
You can make a website with out a single html tag. Just give folder read access to all your directories, have sensible file names. From here you user will be able to browse images , read text files, download videos and depending on the content he may or may not come back ever again, but you do achieve the goal of setting up a "website" with out a single line of html or css or any other code for that matter.
:-) :-) :-)
You can host a telnet server with anonymous access and a specialized shell that restricts the user to doing whatever it is you want the site to do. ;)
Lets make the distinction between what is required by the web browser, and what you as a developer use to create that markup.
Remember that HTML nowadays is xml. You could use any markup language you like and convert that to HTML using XML.
eg ASP.NET uses markup such as which is converted on the server to .
As long as the content going down the wire to the browser is HTML, or generates HTML through script, you can use any approach you like.
However these approaches have mostly failed as developers prefer having direct control over the markup. It makes css as well as scripting much easier when you are certain what the html is going to be.
ASP.NET MVC is a product created in response to criticisms leveled at the ASP.NET webforms model.
Also, this is another answer because it's a completely different technology, but you can write an application in XUL and it'll run in Mozilla-based browsers without any HTML.
There's also XML. You can create websites with XML only. A well known one is World Of Warcraft. Check the page source. An XSL is used as stylesheet. There exist even XML based web frameworks like OpenLaszlo. You can let it serve either DHTML or Flash on reqeust out of a single XML template.
The Wt C++ Web Toolkit.
You can write your web application in C++ using Qt-style widgets (input boxes, buttons, tabs etc) and hook up client-side events to C++ code on your server. All without writing any HTML or CSS.
A sample application from their website (you may also want to look at this excellent tutorial):
HelloApplication::HelloApplication(const WEnvironment& env)
: WApplication(env)
{
setTitle("Hello world"); // application title
root()->addWidget(new WText("Your name, please ? ")); // show some text
nameEdit_ = new WLineEdit(root()); // allow text input
nameEdit_->setFocus(); // give focus
WPushButton *b = new WPushButton("Greet me.", root()); // create a button
b->setMargin(5, Left); // add 5 pixels margin
root()->addWidget(new WBreak()); // insert a line break
greeting_ = new WText(root()); // empty text
/* when the button is clicked, call the 'greet' method */
b->clicked().connect(this, &HelloApplication::greet);
}
void HelloApplication::greet()
{
/* set the empty text object greeting_ to greet the name entered */
greeting_->setText("Hello there, " + nameEdit_->text());
}
Curl (requires a browser plugin)
Wikipedia article
A webpage looks like this:
{curl 1.7 applet}
{value
let b:int=99
let song:VBox={VBox}
{while b > 0 do
{song.add b & " bottle(s) of beer on the wall,"}
{song.add b & " bottle(s) of beer."}
{song.add "Take one down, pass it around,"}
set b = b - 1
{song.add b & " bottle(s) of beer on the wall."}
}
song
}
Source
Since browsers view HTML, I'm assuming you mean create a site without ever having to edit/write HTML/CSS. The framework/app environment/whatever taking care of everything for you - yet still allowing you control over the presentation layer.
Seems like that is certainly possible on a theoretical level.
I ran across Noloh (not one line of html) a while back. Was intrigued, but never actually tried it out.
From various places on the Noloh site:
Because NOLOH does not rely on HTML or pages, maintaining complex rich Internet applications is significantly easier than with other methods.
Developing applications with NOLOH only requires using a single, unified language: a superset of PHP that completely maintains all aspects of server-client communication for you!
I think you could build a site entirely in SVG.
The front page of emacsformacosx is almost entirely SVG, for example.
Downsides: It wouldn't be viewable in IE (at least through version 8). And last I looked, text support, like flowing and justification, was weaker in SVG. (You could embed HTML inside an SVG element when you needed sophisticated text features, but that would violate your no-HTML rule.)
You'd probably still want to use CSS with SVG, because it's a good idea there for the same reason it's a good idea with HTML, but it wouldn't be necessary.
A website is always viewed through a browser (at least always if you are human :)). Browsers understand HTML. Whatever the technology - you have to basically render HTML. Even in cases with rich technologies like flash, the flash object that is rendered by a browser plugin is embedded inside the HTML.
In theory it is possible to do it without HTML, but the question becomes how much does the product diverge from the definition of a website...
One really short, simple answer... you can't :D
Flash requires an embed tag, an image requires an embed tag etc, so you'd have to use HTML in some method or another.
PHP is an embedded language, it is used to generate HTML on which the browsers renders, with XML, well technically a browser like Ie or FireFox will render it in it's own way for readability, but I would not class that as a website.
The major developments in the world of web technologies involves the development of HTML and CSS to improve them, there isn't any need for an alternative. In fact we're pushing towards a standard, what point would there be in introducing a new language to negate these standards. The whole IE saga would simply get worse.
Like the others have suggested, you could directly load an image or a flash file, but an image is useless on it's own, and a flash interface throws up loads of problems like SEO, accessibility etc, not least it's very heavy and usually completely misused. In my mind I wouldn't even class this method as a website, it just doesn't tick any of the boxes (IMO).
I think you can have an URL pointing directly at a hosted Flash (SWF) file, I've certainly done this though I don't know if all browsers work.
Anyhow, I tested this when developing MyDinos.
e.g: http://mydinos.com/home.swf
You can use Emscripten and its SDL subset.
You could try using quickstatic. You can code HTML templates from Python3. What is super cool about it is the fact that if you put in a for-loop for a certain item, you can generate that many items (maybe even use it to print items from a directory or quickly serve thousands of links).
possible duplicate: What tools to automatically inline CSS style to create email HTML code ?
note from author: Oh yeh, definitely duplicate. Sorry.
In general, HTML emails do not support proper CSS techniques.
However, it's nice to develop in these techniques because it makes it a lot quicker to play around with changes etc. (I don't need to sell the benefits of CSS to you all!)
Is there a tool that will take lovely HTML and turn it into nasty email compatible HTML with all the styles extrapolated from the CSS files and placed inline?
Even though 100% compatibility cannot be achieved due to the numerous differences in email clients out there, a tool that helps the process would be very useful, even if it simply takes the CSS and inlines it.
Campaign Monitor have an excellent guide to CSS support in email clients as of 2008. It's very comprehensive.
There are no standards for "email compatible" CSS or HTML, so a tool to perform this task is unlikely to exist. Various client strip out different tags and attribues, especially web-based ones. A lot of it is trial and error. Trial and error is difficult to automate.
I imagine you could run the text of the page through a script that will discover CSS classes and ids and store the styles for them in an array, then go through and replace class="class" with style="style" and id="id" with style="style" etc. It would just be a matter of programming the thing.
Unfortunately, I don't know of any tools, but I would think this could be done using javascript (using jQuery, prototype, or other js framework), to rip through the rendered DOM and discover applied styles and create new HTML based on that
A good start would be to have a source div tag and a target div tag and see that the HTML in the target ends up looking like the source.
Just wrote blog post about converting "good" HTML/CSS into bad, but compatible HTML/inline CSS.
I personally use Premailer for this task, you can read more about it in my post: http://www.versapay.com/developer-blog/the-art-and-science-of-email-rendering-across-email-clients/
Yes, In my experience the best are:
http://premailer.dialect.ca/
http://beaker.mailchimp.com/inline-css
http://zurb.com/ink/inliner.php
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Getting contradictory messages about that, hope they're not.
I cannot imagine support for it would stop, since a gazillion sites use them.
Some additional questions about that:
Why should they phase out this tag?
Any alternative for it?
Support for <iframe> is still there in HTML 5, so I don't think this will change in the near future.
To answer your other questions:
<iframe>s (as frames in general) are most of the time not user-friendly:
They don't allow easy access of the content in the frame via an URL (without losing the content outside of the frame at least).
Most "technophobe" users are irritated by frames.
As far as I know they are slower to render for browsers
Alternatives include dynamic page generation (SSI, PHP, Rails and so on) and using JavaScript / AJAX to change contents of e.g. a <div>
To be clear: I'm talking about <iframe> as an interface element. Not a hidden element for loading other stuff like e.g. Google Mail does.
In my opinion the W3C jumped the gun in dumping iframes from the Strict HTML and XHTML doctypes. In theory you would use the <object> element to add foreign objects to your document, but browser differences and limitations have made this a nonstarter for many developers. With the much-more-pragmatic HTML 5 (which is still a draft), iframes are back and even have two new attributes: seamless, and the intriguing sandbox.
IFrames are not obsolete, but the reasons for using them are rare.
Using IFrames to serve your own content creates a "wall" around accessing the content in that area.
For crawlers like Google, It's not immediately clear that cotent in an iframe will be ranked as highly as if the content were simply part of the page. For many, this is reason enough not to use it.
It makes the DOM for the IFrame less accessible by tools like jQuery, prototype etc..
Reasons for using iframes:
It's great for walling off other people's stuff from other domains but it doesn't integrate smoothly. (stylesheets, javascript etc...)
Integrating multimedia can sometimes be done easier via an iframe as opposed to using the embed tag.
Really, really specialized cases like gmail's case where they are using it for sounds and history management.
I would also answer that there is no need for the removal of iframes, it's a needed tag and will be around for a while.
Iframes are obsolete for page layout. Never use them instead of good CSS layout, even table-based layout is better.
Good reasons for using iframes are:
ads: adwords for example uses this technique, it is good for encapsulating - ad css won't destroy your page.
hidden iframe: it can be used for hundreds usable things, like tracking, ajax-alternative, etc.
I've seen lots of forums that suggest the Object tag as a replacement for IFrame, which probably works in most cases.
For example, I had a PDF showing in an IFrame (because there were other things we need to show on the page besides only the PDF) and was able to get it to display fine using Object.
What was:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
Became:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
But Object was not a suitable replacement to fill the requirement to be able to print ONLY the PDF portion of the page.
An IFrame is like its own window within the page (a window within a window, basically), and once you get the window object, you can call .print() on it, like:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame has a contentWindow property, that's what makes printing only that part possible. Object does not have a contentWindow property, so there's no way to print only the section of the page.
So, it seems like if you're just using IFrame to display something, there's other tags like Object that can be used instead. But if you need to interact with the contents of the IFrame in certain ways, then IFrame may be necessary.
IFrames are used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.
IFrames are not dead, but Frameset/Frames are dying.
In the last 2 releases of IE (IE7/IE8) zooming in Frames (not IFrames) has created disastrous results.
By all means use IFrames, but IMHO stay clear of Framesets/Frames.
At my previous company, we provided a hosted application that customers would integrate into their own websites. At times, they would use an IFrame to do this, fitting our hosted page into their existing designs. Sometimes this was even done seamlessly (ie. the IFrame had no borders or scrollbars, it just looked like part of the page). I considered this to be a good use of the tag.
They can be extremely useful in some circumstances, but those are limited. In particular embedding common functionality across multiple sites.
For example I have a client who runs a number of Scottish goods e-commerce sites. As part of this we have developed a couple of simple applications to locate possible clan names from your surname or your choice of tartans (giggle if you wish but tartans are worth $700 million a year to our economy). The database behind this is surprisingly large (nearly ten thousand rows in the core names and tartans tables) and fairly regularly updated.
So we have the applications set up to run on one website and then embedded these into our other websites using an iframe, enabling simple javascript parameter passing so we can integrate the selection of a tartan or clan with functionality on the embedding site. The iframe is set as noborder so it appears completely seamless to the end user.
Of course there would be other ways of doing this, but the use of an iframe is simple and robust. And it's certainly not obsolete.
Horses for courses... <iframe>s are like anything else... for the right purpose they're the right tool; for the wrong purpose they're an ugly hack, or worse.
In Ajax, <div>s are often the more appropriate container. In some places the activity of passing-off external content as part of your own site, as supported by <iframe>s, is inappropriate.
My team used an <iframe> the other day as an ideal way to give users access to their HTML e-mail history - the e-mails were complete <html> pages which we wanted to insert easily into our web template. <iframe>s were absolutely perfect for presenting that data]'.
On the other hand, <iframe>s should almost always be removed or disabled in any user-submitted content which is output back onto the site, because in that context they are a major security issue.
The google gadget specification currently relies on iframes: http://code.google.com/apis/gadgets/docs/spec.html
Currently they are the only simple way to provide isolation for javascript apps that are pulled from multiple domains/providers.
Also many of the widgets that people embed on their websites from third-parties use iframes.
While they do have their drawbacks, iframes provide a pragmatic solution to common problems on the web. I'd have to guess that they will be around for some time to come.
Compliance and Security issues can also drive you to use Iframes; Shopping carts are popular IFrame-based implementations when you want to visually incorporate a shopping cart as part of some web pages without taking on full responsibility for the payment processing side of things.
We commonly deliver an Iframe to integrate our eCommerce stuff and clients like how turnkey it can be.
I work for a company that used frames for everything from pull down menus, lists, content blocks, etc just to cover the intricacies of .net web forms. The application is very slow and only runs on IE. Don't do this.
In my Delphi program I want to display some information generated by the application. Nothing fancy, just 2 columns of text with parts of words color-coded.
I think I basically have two options:
HTML in a TWebbrowser
RTF in a TRichEdit.
HTML is more standard, but seems to load slower, and I had to deal with The Annoying Click Sound.
Is RTF still a good alternative these days?
Note: The documents will be discarded after viewing.
I would vote for HTML.
I think it is more future oriented. The speed would not concern me.
The question of HTML or RTF may be irrelevant. If they are just used for display purposes, then the file format doesn't matter. It's really just an internal representation. (Are any files even being saved to disk?) I think the question to ask is which one solves the problem with the least amount of work.
I would be slightly concerned that the browser control is changing all the time. I doubt the richedit control will change much. I would lean towards the richedit control because I think there is less that could go wrong with it. But it's probably not a big deal either way.
Have you considered doing an ownerdraw TListView?
I'd also use HTML. Besides, you just got an answer for the clicking sound in TWebBrowser.
If you'd rather not use TWebBrowser, take a look at Dave Baldwin's free HTML Display Components.
I would vote for HTML, too.
We started an app a while ago...
We wanted to
display some information generated by the application. Nothing fancy, just...
(do you hear the bells ring???)
Then we wanted to display more information and style it even more....
...someone decided, that RTF isn't enough anymore, but for backwards compatibility we moved on to MS Word over OLE-Server. That was the end of talking about performance anymore.
I think if we would have done that in HTML it would be much faster now.
RTF is much easier to deal with, as the TRichEdit control is part of every single Windows installation, and has much less overhead than TWebBrowser (which is basically embedding an ActiveX version of Internet Explorer into your app).
TRichEdit is also much easier to use to programmatically add text and formatting. Using the SelStart and SelLength, along with the text Attributes, makes adding bolding and italics, setting different fonts, etc. simple. And, as Re0sless said, TRichEdit can easily be printed while TWebBrowser makes it more complicated to do so.
I would vote RTF as I dont like the fact TWebBrowser uses Internet explorer, as we have had trouble with this in the past on tightly locked down computers.
Also TRichEdit has a print method build in, where as you have to do all sorts of messing about to get the TWebBrowser to print.
Nobody seems to have mentioned a reporting component yet. Yes, it is overkill right now, but if you use it anyway (and maybe you already have got some reporting to do in your app, so the component is already included) you can just display the preview and allow to print / export to pdf later, if it makes any sense. Also if you later decide that you want to have a fancier display there is nothing holding you back.
If both HTML and RTF won't satisfy your need, you could also use an open source text/edit component that supports coloring words or create your own edit component based on a Delphi component.
Another alternative to the HTML browser is the "Embedded Web Browser" components which I used a few projects for displaying html documents to the user. You have complete control over the embedded browser, and I don't recall any clicks when a page is loaded.
I vote for HTML also
RTF is good only for its editor, else then you'd better go standard.
RTF offers some useful text editing options like horizontal tabulator which are not available in HTML. Automatic hyperlink detection is also a nice extra. But I think I would prefer HTML, if these features are not required.
I vote for HTML.
Easier to generate programmatically.
Widely supported.
Since you don't need WYSIWYG capabilities I think HTML advantages trump RTF. Moreover, should the need to export generated data for further, WP-like editing arise, remember that major word processor can open and convert HTML files.
Use HTML, but with 'Delphi Wrapper for Chromium Embedded' by Henri Gourvest , Chromium embedded uses the core that powers Google Chrome.
Don't use TWebBrowser, I'm suffering from all programs that use IE's web control - the font is too small on my 22' monitor with a 1920x1080 resolution, I use Windows 7 and my system's DPI is 150% (XP mode), I tried everything to tweak trying to fix that, no luck...