In Opera's implementation, the author does not specify the size of the output medium or where page breaks go. The browser will automatically lay out the content it finds room for given the constraints of the device. If there isn't room for all the content, new pages will be created. These can be accessed with PgDn/PgUp, gestures, or by controls added through JavaScript.
True, is possible to split content into pages by way of JS. And JS libraries mean that not everyone have to write that code. But I challenge you to write a script that emulates the kind of layouts we are seeing here:
http://people.opera.com/howcome/2011/gcpm/ss
Each row is a series of pages from the same article.
PgUp/PgDown in a scrolled view will often cut of text at the top/bottom. In many cases, pages will be more beutiful, and more readable. Of course, if you prefer to use a scrollbar, you will be allowed to. Just set '* { overflow: visible } in your personal style sheet.
Ford sold Think in 2003. The unit Dean has been playing with is a new model produced within the last year. Here's the full story:
http://en.wikipedia.org/wiki/Th!nk_City
Seems to me that if you are wanting to make a point about using HTML and CSS to distrubute data, you would distribute your paper arguring this case in the same format.
The HTML and CSS source files are available from that page. The PDF file is also there to show, in a frozen format fit for a printer, what can be generated directly from HTML/CSS.
You make many true statements in your post. However, this one is false:
While I think that CSS is far from perfect (it WAS, ironically enough, inspired by a concept from Microsoft after all)
CSS found inspirations in many places, but not at Microsoft. Microsoft were actively involved in the W3C group that produced CSS1, but they didn't inspire it.
It was about ten years ago that I saw Hakon present CSS to some of the engineers and product managers at Netscape, where I was a technology evangelist. That was a great moment in my career, where I knew how much trouble we had with the rendering engine as well as how much responsibility we had to fight the good fight for standards.
What I meant was a footer that will always be at the bottom of a page "in dependance of the content" (as I mentioned). That means, it's at the bottom of a viewport until the content gets larger, which would then push down the footer accordingly.
One possible way of addressing this is to use float: bottom. This construct is described in the recently published CSS3 module: Generated Content for Paged Media. In the draft, it only applies to paged media, but it seems quite intuitive that it has the effect you describe in continous media. What do you think?
Why doesn't CSS allow web designers to specify styles per user agent?
It has been proposed and rejected many times. The basic problem with it is the same as for the User-Agent header in HTTP: every browser will be forced to lie about who they are.
Why didn't the W3C provide a compliance test to allow browser developers to determine if they were implementing CSS properly?
W3C published a CSS1 test suite which has been very helpful. A similar test suite for CSS2.1 is being worked on. However, it's a lot of work and it tends to lag behind the specification. They are called "test suites" instead of "compliece suites" for a good reason: It's almost impossible to write a suite of tests that, if you pass, guaratees complience.
Why does CSS order content according to "top-down left-right" page flow?
This is typically how Latin scripts are rendered. However, CSS can also be used to style right-to-left text as well as well as LTR/RTL combinations. Work is underway to give better support for vertical scripts.
Does the W3C consider CSS to be a success, given the number of people that have to resort to browser hacks to use it?
I'm not speaking for W3C (any more) but I belive W3C is happy to see the widespread use CSS has achieved. I also think it's fair to say that there is some frustration about vendors who do not fix reported bugs and thereby force web designers to resort to hacks. IE7 will fix some long-standing problems and we should cheer the developers to continue their important work.
Lie recommends people download Larabie's "Goodfish" familyrabie's "Goodfish" family
No, I don't recommend people download Goodfish. Rather, I recommend that browsers are modified so that they can download Goodfish and other TrueType fonts.
Goodfish's primary distribution site (myfonts.com) also wants you to register
You'll find Goodfish in the "larabie-straight" package in Ubuntu. No need to register. Just "apt-get install larabie-straight".
Goodfish is only licensed for 1-5 users to use the fonts
I have never seen this restriction in any of my Goodfish files. Where did you find it?
Goodfish faces many of the same practical problems Microsoft's Corefonts families doincomplete sets of glyphs for certain sets of characters making the font families not so useful or downright useless for some users.
No single font family will be all things to all people. But, by supporting web fonts, browsers will make it possible to point to a suitable font -- one that looks right or one that has the right unicode coverage.
In your own followup message you stated that you perhaps had mixed up horizontal and vertical and that your question was about vertical placement of content. You may have seen that I answered another question about vertical placement. The www-style mailing list is a good place for posting concrete proposals, I'd be interested in seeing yours there once the vertical/horizontal issue has been sorted out.
I think that this is needless confusion, and the answer given by Håkon appears to be flippant.
I didn't intend to be flippant. However, I don't agree this is real problem. The problem of having to rewrite all style sheets when new hi-res devices comes along is more serious.
Why not just create a specific server-side language which is browser agnostic and plan for it to be implimented by a specific date, starting over and making it the web 'standard' with several stages in its implimentation?
I'm quite happy with the web as it is, and I believe it's better to build on what we have than to start over again. However, the web is a most generous place and you are welcome to define your own favorite language and argue for its use.
It's true that XSL is mostly used on the server side and that CSS is mostly used on the client side. Generating a PDF document, which is the topic of the article, is something that can happen on both sides; a web site may want to offer PDF for download and users may want to generate PDF for printing a local copy. Therefore, the server/client issue is orthagonal to the issues discussed in the article.
The article compares how two different languages describe the same task (namely, formatting a W3C document). I thint that's a reasonable basis for comparison even if the languages have different scopes (as the XML.com article also notes).
Never ascribe to malice that which is adequately explained by incompetence.
This is the standard Microsoft response whenever they are caught red-handed. I've heard it from a dozen of their employees -- we should start logging this statement...
(Please note that I didn't write the message you responded to, see my homepage for an explanation)
We credit the person writing the JavaScript version of the Encheferizer in Opera's "About" box. The other people involved are credited in our version of the script
Yes, we've added support for @media hanheld (and siblings). Now, what should happen when we find a "handheld" page. Should we turn off our onw handheld formatting and display the page according to the document's style sheet? Or, should we continute to use our own small-screen rendering algorithms, which are carefully researched?
Slashdot Mirror
In Opera's implementation, the author does not specify the size of the output medium or where page breaks go. The browser will automatically lay out the content it finds room for given the constraints of the device. If there isn't room for all the content, new pages will be created. These can be accessed with PgDn/PgUp, gestures, or by controls added through JavaScript.
True, is possible to split content into pages by way of JS. And JS libraries mean that not everyone have to write that code. But I challenge you to write a script that emulates the kind of layouts we are seeing here: http://people.opera.com/howcome/2011/gcpm/ss Each row is a series of pages from the same article.
PgUp/PgDown in a scrolled view will often cut of text at the top/bottom. In many cases, pages will be more beutiful, and more readable. Of course, if you prefer to use a scrollbar, you will be allowed to. Just set '* { overflow: visible } in your personal style sheet.
Ford sold Think in 2003. The unit Dean has been playing with is a new model produced within the last year. Here's the full story: http://en.wikipedia.org/wiki/Th!nk_City
Actually, I cleaned up the mechanical translation after if was first posted here; http://www.noooxml.org/forum/t-93970/norwegians-leave-their-standards-body-in-protest The mechanical translation was pretty good, but still needed 15 minutes of editing.
You make many true statements in your post. However, this one is false:
CSS found inspirations in many places, but not at Microsoft. Microsoft were actively involved in the W3C group that produced CSS1, but they didn't inspire it.
howcome
Wow. Thank you for remembering. And posting.
-h&kon
One possible way of addressing this is to use float: bottom. This construct is described in the recently published CSS3 module: Generated Content for Paged Media. In the draft, it only applies to paged media, but it seems quite intuitive that it has the effect you describe in continous media. What do you think?
Cheers,
-h&kon
Cheers,
-h&kon
Cheers,
-h&kon
In your own followup message you stated that you perhaps had mixed up horizontal and vertical and that your question was about vertical placement of content. You may have seen that I answered another question about vertical placement. The www-style mailing list is a good place for posting concrete proposals, I'd be interested in seeing yours there once the vertical/horizontal issue has been sorted out.
Cheers,
-h&kon
Cheers,
-h&kon
Cheers,
-h&kon
It's true that XSL is mostly used on the server side and that CSS is mostly used on the client side. Generating a PDF document, which is the topic of the article, is something that can happen on both sides; a web site may want to offer PDF for download and users may want to generate PDF for printing a local copy. Therefore, the server/client issue is orthagonal to the issues discussed in the article.
The article compares how two different languages describe the same task (namely, formatting a W3C document). I thint that's a reasonable basis for comparison even if the languages have different scopes (as the XML.com article also notes).
No, CSS works fine with generic XML and you don't need to convert it to xHTML first. Prince, Opera, Mozilla and others support this.
Never ascribe to malice that which is adequately explained by incompetence.
This is the standard Microsoft response whenever they are caught red-handed. I've heard it from a dozen of their employees -- we should start logging this statement...
(Please note that I didn't write the message you responded to, see my homepage for an explanation)
We credit the person writing the JavaScript version of the Encheferizer in Opera's "About" box. The other people involved are credited in our version of the script
-h&kon
The CTO of Opera Software uses the handle "howcome".
http://people.opera.com/howcome
Please stop using my name when you sign your messages.
Somebody signed the message above with my name. I did not write it. My signature is "howcome", not "howcoome".
Håkon Wium Lie
Actually, it uses W3C's Document Object Model to alter the text on the page. You can check the script from:
http://www.opera.com/js/bork/encheferizer.js
This is untrue. Opera6 displays the page which is sent to MSIE6 just fine. You can see screenshots on this page.
Håkon Wium Lie
CTO, Opera Software
This is not correct.
Opera6 shows the page that MSIE6 receives just fine. I even included a screenshot of it on my page -- scroll down to the second image.
If you still believe this is Opera6's fault, please provide a test case showing how it fails.
Yes, we've added support for @media hanheld (and siblings). Now, what should happen when we find a "handheld" page. Should we turn off our onw handheld formatting and display the page according to the document's style sheet? Or, should we continute to use our own small-screen rendering algorithms, which are carefully researched?
-h&kon (of Opera)