Skip to main content

Home/ In-the-Clouds-with-SOA-XML-and-the-Open-Web/ Group items tagged webkit

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

BOOK Offered Or Kept: Digital reading without Epub? | TeleRead: Bring the E-Books Home - 0 views

www.teleread.org/...t-digital-reading-without-epub

ajax book css ebook epub html-5

shared by Gary Edwards on 30 May 08 - Cached
    • Gary Edwards
      Gary Edwards on 30 May 08
       
      .wiki is the native wikiWORD language for MSOffice "editors". It's really AJAX for documents, with HTML+ handlign the "structure", and CSS+ handling the "presentation". We need javascript to perfect the full range of typographical options used by knowledge workers makign their way from MSOffice to the web. BOOK is a good place to start.
  • The structure of a BOOK would look like this: …BOOK/ ……index.html ……images/ ………cover.png ……css/ ………base.css ………skins/ …………modern.css …………classic.css …………nouveau.css ……scripts/ ………prototype.js ………base.js ………extensions.js
  • As for the Javascript, it’s based on the ECMAScript standard, which has evolved into a strongly-typed, object-oriented programming language and is one of the few web “standards” which really is a standard. BOOK authors will welcome the addition of a scripting language, as it is NOT currently supported in the IDPF specifications. In fact, it’s forbidden for .epub reading systems to execute scripts. It’s also forbidden for them to display a file called index.html without first loading and parsing several other files.
  • ...10 more annotations...
    • Gary Edwards
      Gary Edwards on 30 May 08
       
      Good point! The IDPF ePUB format does not support javascript! Which makes "BOOK" a better format to target.
  • For BOOKs, it offers true pagination, typesetting, skinnable and collapsible layouts, footers and headers, footnotes as popups, inline text, true footer notes, or endnotes . . . the list goes on. YUI, JQuery, dojo, MooTools, and Prototype are just a few of the frameworks available, and they’ve been addressing these issues for some time now.
  • Jon Noring Says:
  • EPub is an excellent, high-fidelity format for both direct rendering and for user-side conversion to other formats for particular platforms such as very limited resource handheld devices.
  • Javascript is useful mainly for rendering, not bells and whistles. Without Javascript, the non-normalized implementations of CSS out there become useless–you can’t rely on them to produce a consistent rendering of a document. Unfortunately, with CSS3 the rendering game is only going to get more complicated. I don’t advocate executing scripts from epubs, I advocate executing scripts in epub reading systems. Two very different things, as you’re aware.
  • Scripting is *essential* for many digital publishing projects and not understanding it is a major failure of IDPF. Saying that “we will reconsider scripting when adoption of epub grows” is also inadequate, because nobody will wait patiently, but will choose some another platform for their publishing needs, Adobe AIR for example.
  • My criticism of epub is not about details but about its fundamentals. It seems to me that while preparing the spec the most fundamental question was left out of view: what is the right model for digital publication: is it a physical book? Or is it something else? If something else, then what? From my point of view, not a physical book, but a website should be thought as the right model. Why website? - because of the well supported and ubiquitous mix of technologies (html, css, javascript) and because of the workflow (publishing early versions of the publication on the website for gathering feedback and then publishing as downloadable file). If a model for a digital publication is a website, then any format which does not allow to have everything which we have on websites and does not allow to take all website’s html, css and client-side scripts and publish them as downloadable file without much changing them, is doomed to failure in the long run. It seems that epub is now on this way to failure.
  • What I’d like to see is a sort of epub spinoff, another specification from the IDPF, if you will, with slightly different requirements. Instead of BOOK, we could call it epub-lite. The basis for this simplified, consumer-oriented version of .epub would be the same browser-centric building blocks under the IDPF specs. The difference would be in the file structure and in the way a browser deals with it.
    • Gary Edwards
      Gary Edwards on 30 May 08
       
      What we really need are "webDOCS". Laisvunas is absolutely right. The web is the target, with print and device "flow" an auxillary offshoot. I think we can have it all, and Aaron's "BOOK" is a good place to start. My thinking though is that javascript has to come from standardized libraries such as jQuery or Yahoo's "BrowserPLUS". Yahoo BrowserPLUS does have a security model and off-line capability built in. It's nowhere near as robust and sweepign as the jQuery javascript library, but i don't see why the two can't be combined. Good thinking on the part of Laisvunas!
  • What I wish for is this: a simple ebook format which allows me to use all technologies there are on the web with exactly the same freedom as on web and imposing no additional limitations. Secondly, some browser-based reader (browser add-on or some program based on some quality browser engine). Thirdly, some program (editor/compiler) for producing publications from preexisting web-pages.
    • Gary Edwards
      Gary Edwards on 30 May 08
       
      Once again Laisvunas nails it. I really like his "AIR" suggestion. It's also true that flowing content ready device browsers like the webKit "Safari" and SkyFire will be far more widespread than any ePUB reader!!!!! So why not write for both the web and the device at the same time?
  • The system I’m referring to is alive and well at bookglutton.com. It features an AJAX reader and Package Creation tool. The package tool is currently part of the upload feature which enables people to convert .doc, .rtf, and html documents to epub packages that can be viewed in the Reader. Once we have more epubs out there, direct epub upload will also be an option. We may also eventually enable epub download. Right now, we’re having some doubts about the value of that.
    • Gary Edwards
      Gary Edwards on 30 May 08
       
      How about "eWEB" as a format name? Is it better than "webBOOK" or webDOC"?
  • Gary Edwards on 30 May 08
     
    Aaron Miller writes about the limitations and difficulties with ePUB. He suggests a new format, "BOOK" based on ePUB but web ready. BOOK is an AJAX format in that it includes (X)HTML, CSS and JavaScript! Excellent stuff! The discussion on this page is one of the best on the Web. ePUB gets thrashed, but with arguments very difficult to contest. The web is everything, and Aaron's friends fully understand this. Sadly, the ePUB crowd does not. I found this site looking to solve the problem of numbered lists in ePUB.
Paul Merrell

Do new Web tools spell doom for the browser? | InfoWorld | Analysis | 2008-05-12 | By N... - 0 views

www.infoworld.com/...0FE-web-app-development_4.html

adobe air gears google html5 javascript ria sqlite webkit

shared by Paul Merrell on 16 May 08 - Cached
  • As these technologies mature, a new kind of browser is likely to emerge, one that combines the current Web experience with new capabilities based on emerging tools. The key to that evolution will be to integrate today's cutting-edge features with tomorrow's Web standards -- a process that Adobe and Google are both actively pursuing.
  • Adobe is similarly involved in the standardization process -- in particular, extending ECMAScript, the standard on which JavaScript is based,
  • Despite differences in approach between AIR and Gears, Adobe and Google actually share a common vision. Both companies aim to extend the current Web browsing experience with new features that allow developers to deliver RIAs more easily. And, because Web developers, too, have diverse goals and methods, the traditional browser is unlikely to disappear as an application-delivery platform, even as desktop-based Web apps proliferate.
  • Paul Merrell on 16 May 08
     
    Tomorrow's Web Despite differences in approach between AIR and Gears, Adobe and Google actually share a common vision. Both companies aim to extend the current Web browsing experience with new features that allow developers to deliver RIAs more easily. And, because Web developers, too, have diverse goals and methods, the traditional browser is unlikely to disappear as an application-delivery platform, even as desktop-based Web apps proliferate.
1 - 2 of 2
Showing 20▼ items per page