has anyone tried designing a webpage for psp? - html

I'm trying to make a personal bible for my psp
(I tried googling but the only bible version I've seen on my skimming is on KJV and I'm trying to make mine have 3 versions namely TNIV, NLT and Amplified Bible)
So my only solution was to make on for myself and my approach was to save an html file on my mem-stick and open it up through the console's browser
My concerns are:
How does the psp browser handle css and javascript?
Is there a doctype declaration specifically designed for the psp browser?
Can I use any local database to store my texts for easier query or do I have no choice but rely on static text files?
Is there anyone in SO who have experienced developing a page for this console and can he/she give me some tips and advice?
Thanks much in advance for your responses. :)

Well the best way would be to make an HTML document file to create an off-line web page.

The PSP has good (but not great) CSS support and weak Javascript support (compared to a desktop browser).
The best Doctype to stick to would be XHTML Strict 1.0.
Not unless you find another way to do it.
Not for the PSP, but I would recommend this: Just keep your markup and CSS as simple as possible. Don't set font-sizes or widths, let the PSP browser do that for you. If you need to generate a bunch of static files, it might be worth building a short script that will do it for you. Don't overcomplicate.
Hope that helps.

Regarding my concern #1, I found only this as reference for all script objects that the psp browser supports as of their latest release.. I'm not sure if SCE would add more support for other objects in the future though
Anyhow here's the link

To answer your issue (not your question), have you thought about using http://www.biblegateway.com/ which can show verses in different Bible translations - instead of writing your code to try to do the same thing?
Granted, this only works if you are connected to the Internet.

Related

How can you find out if a specific HTML 5 feature is implemented in a specific browser version?

I imagine there must be out there a website that collects information about HTML 5 feature and what browsers version started to support them.
This might be a good way to decide based on your website profile, if you can apply that HTML 5 feature without a fallback for your visitors.
Do you know such a site/resource ?
For example I want to know what browsers support the multiple upload feature for inputs and what browser version was the first.
Update
I'm not pleased with the sites suggested so I'm opening a bounty.
Suggestions so far: Html5Test, Caniuse, modernizr.com, QuirksMode
Update 2
Some people don't understand the question. I need to implement the multiple upload feature. I know from analytics what browser are they using ( I know this is not 100% correct ).
I'm willing to sacrifice some of the visitors by not offering some advance features but I need to understand how big is this procent. I'm NOT trying to DETECT in anyway the browser. It's a similar approach with other sites that dropped IE 6 support.
So please don't talk about bad practice.
Try to look at Html5Test or caniuse.
If it's server side, you can analyze user agent to find out if client's version supports HTML5. Wikipedia is your friend.
If it's client side, there's Modernizr library.
A quick search gave me this interesting result (reproduced in several blogs): http://www.findmebyip.com/litmus/
And you can may also want to take a look at this list of how to detect each feature: http://diveintohtml5.ep.io/everything.html
Here is another website, quite incomplete but verbose and "work in progress" as of March 2011, so it might be worth keeping an eye on: http://html5accessibility.com/
This one is off topic, but since I found it, I add it. CSS compatibility in IE browsers (very extensive): http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx
And here you can find info specific to the gecko engine: https://developer.mozilla.org/en/HTML/HTML5
And, of course, MDC has compatibility tables for each feature, but separated in different pages, not as a table, e.g.: https://developer.mozilla.org/en/HTML/Element/input
http://www.modernizr.com/
HTML5Test.com collects the information but they don't give detailed reports for perusal.
A good reference site for some stuff is http://www.browserscope.org/ but that doesn't go into a lot of detail with HTML5 specific support
Another source of related stuff is http://w3c-test.org/html/tests/reporting/report.htm which is creating a set of HTML testing tools that can be run.
You or someone who wanted to create this information could use these tests and then store the UA String of each browser that hit the site with the results of each test.
Then you could just find the earliest version of each browser type that a feature successfully run on.
I think this information is stored in the databases of the sites mentioned but they just don't display it which sort of sucks. Maybe try emailing them and suggesting they add these reports.
Take a look at caniuse.com, it’s exactly what you are searching for.
QuirksMode is also a great resource, and there is an entry for multiple files input.
My vote is for:
http://www.findmebyip.com/litmus
Which i found via this blog:
http://www.deepbluesky.com/blog/-/browser-support-for-css3-and-html5_72/
You should try this website. I hope this is what you were looking for.

Flash parser for html

As I was working on this project for a friend of mine who is terrified of changing from HTML to flash, I realized that maybe there could be a bridge between them. So I started working on a flash project that would grab the HTML from his page and parse it to display it in flash. Although I am sure there are resources available for this already, I figured that the experts on SO might be willing to suffer through the logic of one user trying to develop this script.
So basically, I am not asking for an answer, I am asking for some step-by-step direction that could be posted so other people could see the logic behind breaking down this project. I think it would be really useful (not just for me, but for anyone wanting to learn more about objects and oop).
So, much like the thread between primarily Senocular and Rampage, this would be a thread where I would be the student asking the questions in a logical step-by-step manner and someone else (or someones else) could provide guidance.
Let me know if you are interested and I can start by posting what I have already written. We can go from there and I am sure it will prove insightful to anyone who reads it. If no one is interested, or no one has the time or inclination, no problem.
Best wishes,
Jase
Who in their right mind would change from html to flash for displaying a simple website? I don't see the logic behind it, it's more like you are trying too hard. Flash has its function in the web, as well as html does. If it's just for simple displaying, using flash is just the wrong way and won't make your website any better but worse because its loading time will be too long.
Goole Search retrieved these:
HTMLWrapper
Groe.org HTMLParser
There is an article about the 1st on *drawlogic. I think the seconds' home is on sourceforge here.
Thing is, browsers already do a fine job at parsing html code. Having the flash player parse html files not only does away with any accessibility advantage your markup can offer but it also feels like reinventing the wheel. If you need to display html content, leave it to the browser.
Slightly offtopic - Flashpaper can convert most HTML pages into swf format.
Given properly "disciplined" HTML, you can use the XML parser in the player for the basic parsing. Are you really talking about writing an HTML renderer in Flash though? Or just being able to pull information from HTML dynamically?

What to replace FrontPage with?

I use FrontPage for two different tasks; authoring html help and authoring a couple of websites. The websites don't require a lot of stuff -- they are there to disseminate a bit of information to a couple of small audiences.
FrontPage has been quick and easy for these tasks. WYSIWYG is good for these jobs and I like being able to click on links to quickly bring up other pages in the editor.
I've been exploring all sorts of options. tools that work online such as Kompozer make editing the html help difficult (at least, I haven't found a way around) and other html-level tools are just too much work. Tried nVu, Kompozer, Aptama, Komodo, Bluefish and so far, unless I'm missing something, I'm not sold on any of them.
I'm about to take a look at SeaMonkey but wondering if anybody has any recommendations. Or should I go back and look at those other tools again -- maybe I missed something?
Notepad++
I think the natural upgrade path would be Microsoft Expression Web.
People still use FrontPage?
I switched a couple of years back to DreamWeaver and never looked back.
Something to consider is that you could deploy these sites as wikis (which don't have to be publically editable) and edit them directly on the web in your browser. This would give you the ability to click around and do pretty much wysiwyg edits. It would also make it easier to maintain larger collections of data and to make new pages. You also don't really have to do any HTML at all because wikis mostly come pre-HTMLed (and CSSed and Javascripted), you just need to fill in the content.
I should note that this won't work if your webpages are deployed statically on a restrictive shared hosting account, but even most shared hosting supports installing things like wikis these days, so hopefully this is something you can look into.
I should also note that this probably isn't the best way to do local HTML help files, but if the HTML help is online, this is probably still a good choice.
I'm making this community wiki so others can add links to other wikis if they like or add more info on why you might want to or not want to use a wiki for this purpose.
Some wikis to consider:
MediaWiki - The wiki behind wikipedia
MoinMoin - Implemented in Python and popular in that community.
TiddlyWiki - Implemented in Javascript and runs on a single page. This is probably the most different wiki that's out there. Some love it, some hate it.
NVU and Kompozer both are best suited for you. NVU is my personal choice. Choose your poison. :)
FrontPage has been replaced by SharedPoint Designed in the Office suite.
You could also use Microsoft Expression Web if you can have it.
Drewamweaver or MS's Visual Studio/Web Developer Express will do the trick. They're both overkill (especially MS's tools).
I also think MS has (free) HTMLHelp. It's out there, but I don't know if it'll produce the files you need.
It depends on what kind of pages you are designing. If you are using Adobe Flash, Dreamweaver would be the best option but I would recommend "Microsoft Visual Web Developer Express". I am currently using it and totally love it from the bottom of my heart.
I'd say Dreamweaver, but last time I looked there was still bloated code, not as bad as the MX days mind.
Smashing Magazine has a list of WYSIWYG tools that would be worth a look :
http://www.smashingmagazine.com/2008/05/06/25-wysiwyg-editors-reviewed/
I persuaded my friend to ditch Dreamweaver for NetBeans, took a week or so but I got a pint out of that :)
You might look into Aptana (http://aptana.org) which should provide everything you need. I think it even has a WYSIWYG editor, though I would really recommend learning html instead.
I would use Notepad++ for the simpler things, and Dreamweaver when working with other Adobe products. Notepad++ is simple and has a lot of great features. Dreamweaver is huge and will take some getting used to.
Try dokuwiki. I've implemented a wiki/manual/documentation for my app in a week. It's very simple n easy installing. You just need PHP, no database (mysql), the information is stored on files. Give it a try.
My wiki implemented wiki doku: wiki.vigo.com.br
Microsoft Visual Web Developer Express perhaps? http://www.microsoft.com/express/vwd/
Works well, and it's free!
Something similar to FrontPage is Adobe Contribute. It does cost $199, but if you're looking for something as simple as FrontPage, it may be a good option for you.
A freelancer web designer I work with will setup clients who want to make simple HTML edits to their sites with it and they've all been pretty happy. They're all non-technical people.
Dreamweaver is good, but however using the WYSIWYG may have problems getting consistency when viewing between IE, firefox and safari.

HTML or RTF to display columns of text with color-coded words

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

REALLY Simple Website--How Basic Can You Go?

Although I've done programming, I'm not a programmer. I've recently agreed to coordinate getting a Website up for a club. The resources are--me, who has done Web content maintenance (putting content into HTML and ColdFusion templates via a gatekeeper to the site itself; doing simple HTML and XML coding); a serious Web developer who does database programming, ColdFusion, etc., and talks way over the heads of the rest of us; two designers who use Dreamweaver; the guy who created the original (and now badly broken) site in Front Page and wants to use Expression Web; and assorted other club members who are even less technically inclined.
What we need up first is some text and graphics (a gorgeous design has been created in Dreamweaver), some links (including to existing PDF newsletters for download), and maybe hooking up an existing Blogspot blog. Later (or earlier if it's not hard), we may add mouseover menus to the links, a gallery, a calendar, a few Mapquest hotlinks, and so on.
My question--First, is there any real problem with sticking with HTML and jpegs for the initial site? Second, for the "later" part of the site development, what's the simplest we can go with? Third, are there costs in doing this the simple way that will make us regret it down the road? Also, is there a good site/resource where I can learn more about this from a newbie perspective?
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
If you don't require any dynamic content, heck, if you don't plan on editing the content more than once a week, I'd say stick to basic HTML.
Later, you'd probably want a basic, no-fuss and easily installable CMS. The brand really depends on the platform (most likely PHP/Rails/ASP), but most of them can be found by typing " CMS" into Google. Try prefixing it with "free" or "open source" if you want.
I'm pretty sure you can do all this for absolutely free. Most PHP and Ruby CMS's are free and web hosting is free/extremely cheap if you're not demanding.
And last/best tip: Find someone who has done this before, preferably more than once. He'll probably set you up so you never have to look at anything more complicated than a WYSIWYG editor.
Plain old HTML is fine, just as long as you don't use tags like blink and marquee.
I personally love tools like CityDesk.
And I'm not just plugging Joel. (There are others out there in this class I'm sure.) The point is they make making a static website very easy:
The structure is just a filesystem structure
pages have templates to consolidate formatting
all resources are contained in one file
easy and fast Preview and Publish functions
For a dynamic collaborative site, I would just install one of many open source CMSs available on shared hosting sites.
If you're familiar with html/javascript basics I'd look into a CMS - wordpress, drupal, joomla, nuke, etc. All of these are free. Very often your web hosting company will install one of these by default which takes all of the hard part out of your hands. Next is just learning to customize the system and there's tons of docs out there for any of those systems.
All that being said there is noting wrong with good old fashioned html.
In addition to some of the great content management systems already mentioned, consider cms made simple.
It makes it very easy to turn a static site into a content managed site (which sounds like exactly what you might need to do in the future), and the admin area is very easy to use. Our clients have found it much simpler to use than the likes of Joomla.
It's also free and open source.
Good luck!
There's no reason to not go with plain old HTML and JPGs if you don't know any server side scripting languages. Also, once you want to get more advanced, most cheap hosting services have tools that can be installed with one click, and provide things like blogs, photo galleries, bulletin boards (PHPBB), and even content management tools like Joomla.
I had the same problem myself, I was just looking for something really easy to smash together a website quickly. First I went with just plain old HTML, but then I realised a simple CMS would be better.
I went for Wordpress. Wordpress is mostly known as a blogging platform, but in my opinion it is really great as a deadly simple CMS as well.
why not simply use Google pages?
Here is an example of a website I did, takes about 2 hours, easy to maintain (not that I do (-: ) and FREE.
I think that suggesting you mess with HTML for what you need is crazy!
Plain HTML is great, gives you the most control. If you want to make updating a bit easier though, you could use SSI. Most servers have this enabled. It basically let's you attach one file to many pages.
For example, you could have your menu in navigation.html and every page would include this file. That way you wouldn't have to update this one file on every page each time you need to update.
<!--#include virtual="navigation.html" -->
I agree with the other commenters that a CMS might be useful to you, however as I see it, probably a solution like Webby might do it for you. It generates plain HTML pages based on Templates. Think about it as a "webpage preprocessor" which outputs plain HTML files. It has most of the advantages of using a server-based CMS, but without a lot of load on the server, and making it easy for you to change stuff on any of the templates you might use.
It's fine
Rails (or purchase / use a CMS)
Not unless you start becoming crazy-popular
It really depends on what you go with for 2. Rails has a plethora of tutorials on the net and any product you go with will have its own community etc.
To be perfectly honest though, if the dynamic part is someone elses blog and you move the gallery out into flikr you may find that you can actually live with large parts of it being static HTML for a very long time.
If a to Implement a website With User Profiles/Logins, Extensions, Gallery's etc s a Newbi then a CMS like Joomla, Etc are good , but Else if you presently have only Static Content then Its good to go with Good Old HTML, About JPEG , I though Presently Its better to use PNG or GIF as its Less Bulky.
Also About you Query About Shifting to Server Scripts , When you have Database Driven Material or When you have Other Things that Require Advanced Prog Languages , Just use PHP Scripts inside PHP , and Rename teh File as a PHP, Thats IT, No Loss to you HTML Data.....
Do Go Ahead and Launch you Site ......
Dude, you're talking about HTML, obviously you'll be styling your content with CSS. Wait till you run into IE issues and god forbid your client wants ie6 compatibility.
Go with the HTML for now, I'm sure you guys will hack it through. Our prayers are with you.
Personally, I'd never use JPEG images on a website, mainly because of three reasons:
JPEGs often contains artifacts.
Quality is often proportional
with filesize.
Does not support
alpha transparency.
That said, I'd recommend you to use PNGs for images since it's lossless and a 24-bit palette (meaning full colors + alpha transparency). The only quirk is that IE6 and below does not support native alpha for PNGs, however this could be resolved by running a javascript which would fix this issue.
As for designing a website, there's both pros and cons for this. I suggest you read through:
37 Signal's Why We Skip Photoshop
Jeff Croft's Why We Don't Skip Photoshop
As for newbie resources, I'd recommend you flip through the pages at W3 Schools.