So I know (think?) WebGL depends on the element of html5, but is it part of the html5 spec itself?
I used to think they were two different things, much like CSS3 and html5. But then I saw it as one of the criteria tested in http://html5test.com/.
Let's start by identifying what HTML 5 is. The W3C has a spec with a history section that details how the different HTML version numbers came about.
The WHATWG, for its part, considers HTML to be a "Living Standard", free of version numbers, but still includes HTML5 in its description of that standard.
WebGL itself is not part of either of the above specifications directly, although you'll find a reference to it if you search the WHATWG document above. So officially, no, not part of HTML5. WebGL does, as you mention, depend on the <canvas> element from HTML5.
In practice, however, I've seen a lot of people use "HTML5" as a buzzword or umbrella term to refer to the latest web technologies, including WebGL. In particular, you can't always describe an app as being a "WebGL app" because it almost always relies on newer aspects of HTML 5, CSS, JavaScript, etc., to make it work. I've often heard these referred to as "HTML5 apps" even if that's not strictly the definition. It's more modern than saying "Web 2.0" I suppose.
WebGL is not part of HTML 5 specification.But this belongs to khronos group.More info can be had from this link:
www.khronos.org/webgl
Related
At my company we’re looking to implement support for W3C standards, such as SVG 1.1 (2nd edition), in our app. I’ve been doing research on how people approach this problem.
There are various resources available at w3.org, but the standard only appears to be available in HTML files. I would like to be able to parse a single document that gives me all of the concepts in the standard, which I can then generate objects from in a programming language of my choice.
Apart from simply parsing the HTML itself, it seems possible to parse the document type definition file, but this doesn’t include type information for attributes such as “color,” whose constraints are described in EBNF in the html document.
What is the best approach to implementing a W3C standard, such as SVG 1.1 (2nd edition)?
Does it simply come down to manually tracking the different parts of the standard, as defined in the HTML?
I plan to use Xcode to make an app for the iPhone that displays math equations that high school and college students often use. I do all my math with Mathematica, and it allows me to save such equations in three relevant formats. (1) LaTex (.tex); (2) MathML (.mml); (3) XHTMLMathML.
The Mathemactica documentation says the third format is XHTML with embedded MathML. I found some of the examples at this browser test don't look so good on my iPhone. So I will propbably not rely completly on MathML.
I am a total beginner with Xcode and the three file formats that I mention above, but I have some experience with OOP in C++. Assuming Mathematica can do a good job writing the required LaTeX, MathML, XHHTMLMathML needed for whatever equation, what are the tradeoffs between the three file formats? Can I mix the formats in the same app?
I would suggest to use HTML. The "right" way to include mathematical content is MathML -- which is part of HTML5 (but see below for using TeX).
iOS's UIwebview is webkit based and therefore has the same partial MathML support (though on iOS5 it's significantly worse due to a font bug) so I would also suggest to use MathJax (disclaimer: I'm part of MathJax).
MathJax is an open source javascript library which understands TeX and Asciimath input, converts either one to MathML and renders MathML as HTML-CSS or SVG (in any modern browser).
MathJax has no problem mixing these input formats. Additionally, it has better MathML support than webkit (and you can always configure MathJax to use the native MathML support if you want -- say when you know your content should render fine in webkits native support).
To get you started, you can take a look at this open source app to see how MathJax can be integrated in an iOS app.
I need to make an if statement using Ruby that checks to see if the client's browser support HTML5 or not.
Short version: you won't be able to, nor should you.
Long version: It may be possible, if you do some user-agent sniffing, to identify whether or not the user's browser supports HTML5 or not. But this would take a fair amount of effort to get right. The better solution is to use something like Modernizr (http://www.modernizr.com/) to do your feature detection on the client-side.
It's possible to read the browser info based on the HTTP_USER_AGENT string, but, as mentioned above and many other places, it's also really easy to spoof that info. On the server-side we only cared because it gave us an overall view of the client browsers being used to access our sites.
Trying to react to a browser on the backend and present different content was tried by sites for a while, but it fails because of how browsers spoof other browsers, but don't have the same bugs.
As #Stephen Orr said, CSS is a better way of dealing with it. Sure it's hell and still error-prone, but it's better than sniffing the browser's signature. We used to cuss every release of IE because it broke the previous fixes. Luckily things seem to be getting better as the vendors creep toward toeing standards.
Most features can be detected (with JavaScript), but some kinds like the form-date-feature field is a problem: http://united-coders.com/matthias-reuter/user-agent-sniffing-is-back
It is possible to do Feature detection on HTML5, to detect single features from HTML5 as you need them. There is, however, no way to detect if a browser supports HTML5 as one big chunk - as there is no "official" way to tell if a browser supports all of HTML5 or just parts of it.
< [html5 element] id="somethingtobedazzledby">
Upgrade your browser
</ [html5 element] >
I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.
I'm looking for an internal representation format for text, which would support basic formatting (font face, size, weight, indentation, basic tables, also supporting the following features:
Bidirectional input (Hebrew, Arabic, etc.)
Multi-language input (i.e. UTF-8) in same text field
Anchored footnotes (i.e. a superscript number that's a link to that numbered footnote)
I guess TEI or DocBook are rich enough, but here's the snag -- I want these text buffers to be Web-editable, so I need either an edit control that eats TEI or DocBook, or reliable and two-way conversion between one of them and whatever the edit control can eat.
UPDATE: The edit control I'm thinking of is something like TinyMCE, but AFAICT, TinyMCE lacks footnotes, and I'm not sure about its scalability (how about editing 1 or 2 megabytes of text?)
Any pointers much appreciated!
FCKeditor has a great API, supports several programming languages (considering it is javascript this isn't hard to achieve), can be loaded through HTML or instantiated in code; but most of all, allows easy access to the underlying form field, so having a jQuery or prototype ajax buffer shouldn't be terribly difficult to achieve.
The load time is very quick compared to previous versions. I'd give it a whirl.
In my experience a two-way conversion between HTML and XML formats like TEI or DocBook is very hard to make 100% reliable.
You could use Xopus (demo) to have your users directly edit TEI or DocBook XML. Xopus is a commercial browser based XML editor designed specifically for non-technical users. It supports bidi and UTF-8. The WYSIWYG view is rendered using XSLT, so that gives you sufficient control to render footnotes the way you describe.
As TEI and DocBook don't have means to store styling information, those formats will not allow your users to change font face, size and weight. But I think that is a good thing: users should insert headers and emphasis, designers should pick font face and size.
Xopus has a powerful table editor and indentation is handled by nesting sections or lists and XSLT reacting to that.
Unfortunately Xopus 3 will only scale to about 200KB of XML, but we're working on that.
I can't really decide on one of them. IMHO they are all not very good and complete. They all have their advantages and clear disadvantages. If TinyMCE is your favorite then afaik, it also does tables.
This list will probably come in handy: WysiwygEditorComparision.
I've also used FCKEditor and it performed well and was easy to integrate into my project. It's worth checking out.
Small correction to laurens' answer above: As of now (May 2012), Xopus supports UTF8, but not BiDi editing. Right-to-left text is displayed fine if it came from another source, cannot be edited correctly.
Source: I was recently asked to evaluate this, so have been testing it.