Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Håkon Responds to Questions About CSS and... 204

You submitted questions for Håkon Wium Lie on June 20. Today we have his answers, not only to the (+5 moderated) questions we sent him, but to a bunch of others he thought would also be interesting to answer.
 > Where... by bcat24
 >
 > Do you think the W3C development process is too slow? I know that
 > you guys want everything to be perfect, but it seems to take far
 > longer than necessary. CSS 3 shows promise and I wouldn't want it
 > to die a slow death in standardization.

No, I don't think W3C is too slow. W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead. Rather, the CSS Working Group in W3C has focused on specification maintenance and achieving interoperability between implementations. This work is not so glamorous and some people — even within W3C — would prefer if they concentrate on new specifications. However, I think the focus on interoperability (which has resulted in CSS 2.1) has been crucial to the success of CSS.

CSS3 is a set of specifications that are developed more or less independently of each other. The best way to push a specification forward is to implement it. In the past year, we've seen some encouraging CSS3 implementations come along. For example, Mozilla supports multi-column layouts, Opera supports media queries, Prince supports cross-references and Safari supports borders and backgrounds. A few years from now, I think a select group of CSS3 modules will be interoperably supported in all browsers.

 > Why is CSS such a good idea but a pain to use?
 > by rar
 >
 > CSS is clearly very useful for separating style from content. But
 > apparently people tend to have problems when using it for layouts.
 > Would you say this is because people have not yet understood how to
 > properly do layout in CSS, or is it CSS that is lacking in this
 > area? What can be done to improve the situation? --- Would the web
 > benefit from HTML and CSS being complemented with some kind of
 > "layout language"?

I think layout and style should be tackled by the same language and the two are intertwined. Trying to split the two is like splitting the HTML specification in two, one specification describing inline elements and the other describing block elements. It's not worth the effort.

I think CSS is capable of describing beautiful and scalable layouts. The CSS Zen Garden has been a eye-opening showcase of what is possible today. If MS IE had supported CSS tables, another set of layouts would have been possible. So, there is still lots of potential in the existing CSS specifications which should be the next milestone. Beyond that, the CSS Working Group has started work on a new CSS3 module for advanced layout. Feedback is welcome.

 > CSS Evolution!
 > by eieken
 >
 > Is the wave of webpages designed completely in CSS what you
 > intially intended when you came up with CSS? Do you see that
 > changing? Is that good or bad?

I saw a clear need for a web style sheet language when proposing CSS in 1994. I also wanted CSS to fully describe the presentation of a web pages -- not just add some styling. All in all, I think it has turned out quite well. It has taken longer than I expected, but the scale -- due to the growth of the web -- is more than anyone could imagine.

I used "I" too many times in the previous paragraph. It's important to realize that CSS is a community effort rather that one man's work. Bert Bos joined me early and we worked out the initial designs on a whiteboard during the summer of 1995. The www-style mailing lists and the W3C CSS Working Group have also been crucial in ensuring the success of CSS.

If you're interested in the history of web style sheets, you'll find plenty of material in my PhD thesis on the subject.

 > Two questions (cut to 1.5 by editor Roblimo)
 > by Dolda2000

 > If you were allowed (perhaps by court order, which wouldn't be
 > unthinkable) to force Microsoft to do one (1) change in Internet
 > Explorer, what would that be?

I would force them to support one (1) single web page before shipping IE7, namely Acid2. By using a tiny amount of resources to get Acid2 right, Microsoft can save web designers and users endless amounts of frustration in the future. It would also be an honorable thing to do. This is what Microsoft's W3C representative wrote in 1998:

Microsoft has a deep commitment to working with the W3C on HTML and CSS. We have the first commercial implementation of HTML4, we were the first vendor anywhere to implement even portions of CSS, and we have put a tremendous amount of energy into seeing CSS mature to Level 2. We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).

May I have one (1) more change? Please? Then I would make IE7 support TrueType downloadable fonts. Microsoft's record in fonts isn't that bad. They made their core fonts available for anyone to use, and IE supports downloadable fonts. Unfortunately, only the proprietary EOT format is supported. A few lines of code would be sufficient to support zipped TrueType fonts as well, and this would unleash a new wave of typography on the web. (To protect yourself, make sure you use a browser where author style sheets can be turned off — Shift-G in Opera). > As a bonus question: What do you think of Slashdot's CSS? ;)

The new design looks great! The style sheets behind the scene are more complex than what the average web page needs. But, we wouldn't expect anything average from Slashdot, would we?

> 6)  Opera
 > by taskforce
 >
 > Opera 9.0 seems to offer a lot of decent additions to Opera's
 > standards pool. How satisfied are you personally with the work the
 > team has done on implementing standards, and is there anything in
 > there you feel is superflous and anything you would have preferred
 > to see which wasn't in there?

I'm very proud of the standards support in Opera 9. Acid2 is an obvious favorite of mine and seeing that smiley face makes me very happy.

Among the more experimental features is support for Audio in HTML5. Web applications can now make sounds in a sensible way! Combined with the canvas element, developers can create Flash-like content without resorting to a proprietary format.

Having support for Bittorrent is also great. From a technical point of view, it makes much sense. Also, it's a political statement of sorts.

During the development of Opera9. Geir Ivarsøy, who founded Opera with Jon von Tetzchner, died after fighting cancer for years. Geir did a spectacular initial CSS implementation in Opera, thus convincing me to join the company. In music, the 9th is legendary. Beethoven, Schubert, Bruckner and Mahler all did 9 symphonies. Opera 9 was Geir's last symphony.

> Included styles, aliases
 > by Spy der Mann
 >
 > I always wanted to have "included" substyles or "aliases" in my
 > CSS definition, to save redundancy.
 >
 > (For includes)
 >
 >     .class1 { color:#ff0000; }
 >     .class2 { background-color:#ffffff; }
 >     .class3 { include:class1,class2;font-weight:bold; }
 >
 > (For aliases)
 >
 >     @alias color1 #ff0000;
 >     @alias color2 #ffffff;
 >     @alias default_image url('/img/image1.jpg');
 >
 >     .class1 { color:color1; }
 >     .class2 { background-image:default_image;background-color:co lor2; }
 >
 > This way we could change colors or images for a whole webpage
 > by editing a reduced number of lines.
 >
 > Had you considered any of these ideas in the past? If so,
 > why were they rejected?

Yes, aliases and constants have been considered. As David Wheeler noted, "Any problem in computer science can be solved with another layer of indirection."

CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another -- should that work? If so, what if the first style sheet isn't available?

For CSS1, the downsides of aliases were considered more significant than the benefits.

 > Definition of pixel
 > by Sara Chan
 >
 > The word pixel meant "picture element", but CSS redefined it
 >to mean something quite different (a particular subtended angle
 >of view [w3.org]). This causes confusion: CSS pixels are not pixels.
 >(Indeed, I have seen misinformed comments on Slashdot due to
 >that confusion.)
 >
 > My question is this: why call the subtended angle a "pixel", instead of
 >something else (e.g. "subangle")? If CSS wanted to use the subtended
 >angle for something, that is fine, but calling it a pixel seems to follow
 >the approach of Humpty Dumpty "When I use a word, it means just
 >what I choose it to mean".

In most cases, a CSS pixel will be equal to a device pixel. But, as you point out, the definition of a CSS pixel will sometimes be different. For example, on a laser printer, one CSS pixel can be equal to 3x3 device pixels to avoid printing illegibly small text and images. I don't recall anyone ever proposing another name for it. Subangle? Personally, I think most people would prefer the pragmatic "px" to the non-intuitive "sa".

> Vertical CSS Support
 > by infestedsenses
 >
 > As a developer who works with CSS every day, I find one
 > complication that continues to bother me in my daily work.
 > Support for CSS has always been good on the horizontal scope,
 > but vertical positioning has always been quite complicated.
 > Alone the procedure to affix a footer to the bottom of a screen
 > in dependance of the amount of content is unnecessarily difficult,
 > spawning hackish solutions such as "footerStickAlt"
 > [themaninblue.com]. Centering an object in the dead center of a
 > page also requires strange procedures such as this one [wpdfd.com],
 > which still aren't ideal (try making the viewport really small). The old
 > table method provided much easier methods for this. What are your
 > thoughts on this and do you see improvement following in future
 > CSS revisions?

Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

> About Microsoft...
 > by Chabil Ha'
 >
 > With MS's next browser release (IE 7), you mentioned in other
 > interviews that their decision to not supprt CSS2 was more a political
 > decision than a mechanical one. Aside from their obvious desire to
 > dominate the world, what politics do you think are in play that make
 > them not want to conform to the standard, and what do you think would
 > change that landscape so that they would have some initiative to
 > fully support it?

Great question. It's quite clear that Microsoft has the resources and talent to support CSS2 fully in IE and that plenty of people have reminded them why this is important. So, why don't they do it? The fundamental reason, I believe, is that standards don't benefit monopolists. Accepted, well-functioning, standards lower the barrier of entry to a market, and is therefore a threat to a monopolist.

From that perspective, it makes sense to leave CSS2 half-implemented. You can claim support (and many journalists will believe you), and you also ensure that no-one can use the unimplemented (or worse: buggily implemented) features of the standard. The only way to change the equation is to remind Microsoft how embarrassing it is to offer a sub-standard browser. And to use better browsers.

Another reason for not making a IE too good is that it will compete with Windows. A modern browser is an application platform; the combination of HTML, JavaScript, CSS and DOM allows developers to target the web instead of Windows, Linux, or Mac.

> From linvir
 > How long since you last used Linux?

I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

 > From Rob T Firefly (844560)
 > Why the curly brackets?

The initial CSS proposal didn't use them, instead relying on newlines to separate statements. TimBL didn't really like that and I therefore borrowed the curly braces from the C programming language. The syntax for comments came along as well. I think it works quite well.

 > why not XML?
 > by slashdot.org
 > Simple question (hopefully simple answer ;-)): why
 > did you not use XML?

The simple answer is that the development of CSS preceded XML by a year or so. However, if XML had been available, would we have used it? Probably not. And I suspect Brendan Eich of JavaScript fame would answer the same way on behalf of his language.

XML is a great syntax for structured data, but not suitable for all languages. Still, I think the SGML-based syntax for the FOSI style sheet language.

 > Padding
 > by Anonymous Coward

 > Why was the decision made to make padding apply outside
 > of the width of a 'box', rather than inside, which would seem
 > to make more sense?

It makes sense in some situations, but not in others. For example, when a child element is set to width: 100%, I don't think it should cover the padding of its parent. The box-sizing property in CSS3 addresses this issue. Ideally, the issue should have been addressed earlier, though.

> by nuzak

 > why not float:

 > DSSSL had this sort of thing solved before HTML even existed,
 > let alone CSS. But scheme is too scary and icky, and the W3C
 > believes in a principle of least power, so CSS has to be fully declarative,
 > static, and crippled until patched later.

You're wrong about DSSSL -- it didn't support floating text (as in having text wrap around images) at all. And the DSSSL specification only became publically available around 1996, years after HTML.

> by MagicM

 > How frustrating is it to write a specification knowing
 > that you're at the browser vendors' mercy?

That's part of the game. I don't think any specification has a birthright to be fully supported by all browsers. There should be healthy competition between different specifications. I believe simple, author-friendly specifications will prevail in this environment.

Microformats are another way of developing new formats. Instead of having to convince browser vendors to support your favorite specification, microformats add semantics to HTML through the CLASS attribute. And style it with CSS.

> New standards
 > by iamsure
 >
 > In your work at Opera, you have clearly paved a path that includes
 > going beyond the W3C standards. Whether it is WhatWG
 > implementations, or new functionality specific to Opera (2dgame),
 > you are pushing into new territory. Can you explain why W3C isn't
 > sufficient, and why efforts at Opera to expand beyond the standards
 > differ from Microsoft's embrace/extend model?

It's a fair question. The WhatWG was set up when it seemed as if W3C didn't care much about browsers anymore. That has definitely changed and work items from WhatWG are now channeled into W3C (e.g., XMLHttpRequest).

At Opera, we sometimes include experimental features before they have been standardized. When this happens they are labeled as such, but we still try to document them. For example, we support some Opera-only CSS properties for XML. If these features gain traction, we are happy to work with other organizations to standardize them. If they don't become popular, the features will most likely disappear.

 > Beyond HTML
 > by pr1000

 > How far can CSS be taken beyond the web page--that is,
 > have generalized or non-web specific features for such things
 > as page formatting or type setting? Do you plan/wish/hope to
 > take it farther than it currently is?

Yes, I think it's possible to take CSS further in several directions. I'm eager to see CSS being used in paper-based publishing and I joined the board of YesLogic — which makes the Prince XML to PDF converter — to make sure they added my favorite features. Bert and I used Prince to generate PDF from HTML and CSS sources for the third edition of our book. W3C just published a new Working Draft which describes features for printing, e.g., footnotes, cross-references, and even generated indexes.

For mobile units, I think Media Queries will be important. For example, they can express that large images should not be sent to mobile devices.

Another great opportunity for CSS is Web Applications. Just like documents, applications need to be styled and CSS is an intrinsic component of AJAX. The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:

  • AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
  • ADJACS: Asynchronous DOM, JavaScript and CSS
  • ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
  • AJAHCS: Asynchronous JavaScript, HTML and CSS
  • AJACS: Asynchronous JavaScript, HTML and CSS

Opera, Mozilla and Safari developers are collaborating in the WHAT WG and in W3C to make sure we have interoperable specifications for AJAX. I mean, ADHJACS.

 > by crush

 > Is the difficulty of producing a layout that consists of
 > three or more columns of equal height justification for
 > adding some new feature to the specification to make this easier?

I don't think so. CSS2 defines a table layout that can be used for this purpose. The problem is, and I'm repeating myself here, that the dominant browser doesn't support it. Adding yet more features to the specification wouldn't help.

 > How come, we um, lie?

Right. My name is, um, a bit troublesome to pronounce in English. But I'm a nice person who generally tells the truth. I often tell non-Norwegians that my first name is pronounced "howcome". That's close, but not quite. It does make for a great email address like howcome@opera.com, though.

So I may be a Lie, but I'm just a little white one :-)

This discussion has been archived. No new comments can be posted.

Håkon Responds to Questions About CSS and...

Comments Filter:
  • I'm blind (Score:5, Insightful)

    by gEvil (beta) ( 945888 ) on Friday June 23, 2006 @10:56AM (#15589510)
    Okay, it looks like I am certifiably blind. Time to go adjust some font sizes...
    • Re:I'm blind (Score:5, Insightful)

      by doti ( 966971 ) on Friday June 23, 2006 @11:07AM (#15589578) Homepage
      yep, the default font size for monospaced text in firefox is too small (12, while proportional font is 14, IIRC)
      • yep, the default font size for monospaced text in firefox is too small (12, while proportional font is 14, IIRC)

        Flamebait and troll warning!

        Maybe slashdot should have reported this story _before_ screwing up the site with their CSS overhaul.

        Is it just me? Or are the default sans-serifed fonts difficult to read? Is it just me, or does the blockquoted text seem unimportant and again difficult to read because its a light grey color? Is it just me, or does the fixed font in this article look like crap? Is i
        • If you're using Firefox, try pressing Ctrl-+ to increase the font size in the current tab when you visit Slashdot. It's annoying, but it works for me.
        • Best I can see they *don't* specify a font for the monospaced stuff. Which is a GOOD thing. Damn tiresome with all these silly webpages insisting on using unreadable font/size combinations because some pretentious idiot thinks he's an artiste.

          So if you're having problems reading that, the problem is in your browser, not the page. There should be a setting for default fonts. Yours is set too small. Change it.
      • Re:I'm blind (Score:3, Informative)

        by DrSkwid ( 118965 )
        I set Minimum Font size : 16

        It screws up a few sites (such as Digg) but on the whole, it makes the web much more readable.

      • Re:I'm blind (Score:3, Interesting)

        by Bogtha ( 906264 )

        The default font size is fine. It's Slashdot's new style that did this. If it used the default font size, you'd be able to read it. Slashdot's stylesheets make <pre> elements 93% smaller than the parent element font size. And the parent element font size is already 82% smaller than your default font size. This means Slashdot's stylesheet is essentially saying: "You know that font size you have configured to be readable in your browser? Well I think this text should be 25% smaller than that."

      • It never ceases to amaze me that the slashdot managership will completely ignore the userbase. Everyone is complaining about the disrespectful font sizes, no one is speaking up in support of some idiotic fucking around with our fonts, yet they just leave the situation as-is eternally. Or so it seems. And then they probably wonder why so few people are willing to subscribe. I get to see dupes early? Whoop de shit! Give me something that actually benefits me...
      • Actually it's 13 on my Firefox... I set it to 14 and it looks alot better. Thanks for the suggestion! :)
  • by Rob T Firefly ( 844560 ) on Friday June 23, 2006 @10:57AM (#15589513) Homepage Journal
    Should I be pleased that he answered my question and did so reasonably, or disappointed that that particular beloved gripe of mine now has a reasonable answer from Himself floating around?
  • Formatting (Score:5, Funny)

    by keyne9 ( 567528 ) on Friday June 23, 2006 @10:58AM (#15589519)
    The formatting for the questions is absolutely horrid.
  • > From linvir
    > How long since you last used Linux?
    I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

    Does that mean that you really use Microsoft's corefonts [com.com]? Even though Bitstream Vera [wikipedia.org] is free and kicks mscorefont's ass?

    • Strike that (Score:4, Insightful)

      by linvir ( 970218 ) * on Friday June 23, 2006 @11:05AM (#15589570)

      What a load of crap that comment is. Of course you use corefonts. It's the de-facto standard, it's cross platform, and it's what most people use. You pretty much don't have any other choice.

    • Re:Ubuntu (Score:5, Informative)

      by omeg ( 907329 ) on Friday June 23, 2006 @11:30AM (#15589753)
      As graphic designer, I have to disagree with you on that. Verdana, to me, seems like a better web font than Bitstream Vera. Our favorite free font has just a few kerning issues; Verdana seems to be just a little more fine-tuned for screen display. Fonts on the web should adhere to a couple of design principles that make them more easier to read, such as using a high x-height (the height of the lowercase x letter, and thus the general height of all lowercase letters) and a large punch size (the amount of space in, for example, the middle of an o). Bitstream Vera has a few difficulties in punch size, too, simply using different sizes in different letters.

      I'm certain that the DejaVu project will fix these small issues in time, however. In the meantime, I'll personally happily use Lucida Sans as my sans-serif web font rather than Verdana OR Bitstream Vera. :)
      • Re:Ubuntu (Score:4, Interesting)

        by DarkSarin ( 651985 ) on Friday June 23, 2006 @01:09PM (#15590591) Homepage Journal
        Give me choice or give me something else!

        I happen to like serif fonts. The serif provides just enough extra information to allow for slightly faster processing speed--until you drop down to rather small font sizes. Then you NEED to go to sans.

        I also happen to like mono. Would please someone give me a decent mono serif font (just tell me the name, and whether or not it is free)?

        FWIW, one of the biggest weaknesses in webdesign is user-font dependence. It should be easy to fix with CSS--allow specification of a font directory, and then have the browser auto download and install the font. The font would need to go through virus scan, of course, but the method would by default prevent any executable binary from being downloaded. THis could be done seamlessly and transparently, but I have to admit to some ignorance about what security holes this would open. Anyone care to address this?
        • Re:Ubuntu (Score:3, Informative)

          by Bogtha ( 906264 )

          FWIW, one of the biggest weaknesses in webdesign is user-font dependence. It should be easy to fix with CSS

          Yes, which is why downloadable fonts were added to CSS in 1998 [w3.org]. But nobody bothered implementing it, so it was taken out again.

        • >The serif provides just enough extra information to allow for slightly faster processing speed

          That's a myth, you have the rights to prefer serif fonts, no need to propagate this myth which has been disproved since.
      • Re:Ubuntu (Score:4, Insightful)

        by Bogtha ( 906264 ) on Friday June 23, 2006 @02:11PM (#15591137)

        Fonts on the web should adhere to a couple of design principles that make them more easier to read, such as using a high x-height

        This is precisely the thing that makes Verdana such a lousy font for the web.

        Don't get me wrong, I totally understand what you are saying about the x-height and how it makes text more readable, but the thing about the web is that you can't know that the reader is actually using that font. Sure, you can suggest Verdana, but if they don't have it on their system, or they prefer another font, the x-height you assume to be in use usually ends up being much smaller. This means that what is a perfectly readable font size for you, using Verdana, may end up being totally unreadable for somebody else, because even if the same font size is in use, the lowercase letters all appear much smaller.

        Verdana is a nice font. I actually have it as my browser default. But when it comes to web designers specifying Verdana, it causes more trouble than it's worth. Maybe if they learnt to stay away from messing with the font size it would be okay, but there are precious few web designers who do that.

    • In his news.com editorial, Lie recommends people download Larabie's "Goodfish" family even though the licensing for Goodfish isn't any better than Microsoft's Corefonts, thus a major portion of his editorial makes little sense.

      Goodfish faces many of the same practical problems Microsoft's Corefonts families do—incomplete sets of glyphs for certain sets of characters making the font families not so useful or downright useless for some users. Goodfish's primary distribution site (myfonts.com) also want
    • Comment removed based on user account deletion
  • I just don't think that name has the same hype potential..
  • by Two9A ( 866100 ) on Friday June 23, 2006 @11:09AM (#15589591) Homepage

    AJACS definitely seems to apply better than the AJAX that everyone calls it at the moment: when was the last time you saw XML being thrown over xmlhttprequest, as opposed to plain HTML/CSS?

    I also definitely agree that it's the browser developers (particularly Microsoft) who are dragging their heels on CSS support. Heck, my copy of Firefox 1.5 fails Acid2 hard; fortunately, I know that work is being done there to gain compliance before too long.

    As for printing with CSS, I'm a convert. The last document I wrote that wasn't HTML/CSS was my college final project report, about 2 years ago (that was in TeX); since then, everything I've done has been HTML, styled for screen and print. Heck, even my resume's HTML.

  • by cargoculture ( 929867 ) on Friday June 23, 2006 @11:12AM (#15589621)
    The ability to use position:fixed was not exactly what people were talking about.
    • Yeah, I'd like to thank Håkon for taking the time to answer my question, but it's not really the answer I was looking for.

      position: fixed will stick a footer to the bottom of the viewport, but not to the bottom of a page (perhaps I am not using the correct terminology). That means that if the content is longer than the viewport, the footer will just overlap the content and stay put, while the content beneath it will continue to flow and scroll. What I meant was a footer that will always be at the bo

      • 1. Set html and body to height : 100%; (otherwise they will not fill the viewport properly).
        2. Set your main content element to position : relative; min-height : 100%;.
        3. Put your footer inside the main content element and set it to position : absolute; left : 0; bottom : 0; width : 100%;.

        Caveat: You need to know how high the footer is and add padding/margins to the bottom of the content so that the last bit of content on the page doesn't get swallowed by the footer (which is floating above the content on a
  • Acid2 (Score:5, Informative)

    by Odin_Tiger ( 585113 ) on Friday June 23, 2006 @11:16AM (#15589642) Journal
    Acid2 link from article is dead. You can find the test here [webstandards.org].
    • Someone mod the parent up "Informative"; the link in the article was definitely not right.

      And now having run the test in IE and Firefox, I can honestly say that while they both failed it, Firefox looked a hell of a lot more like the test image than IE did. I think he was right -- standards don't mean much to monopolists.

  • by MSFanBoi2 ( 930319 ) on Friday June 23, 2006 @11:17AM (#15589647)
    Only IE was singled out (of course), but there are not many browsers that pass ACID2...

    Yes, I'm aware Safari does and Opera 9, but Firefox sure the heck doesn't (not unless you wanna roll your own copy anyways)...

    So the two biggest installs of browsers don't pass ACID2, but it's fine to only mention the fact that IE fails it. Especially when Microsoft said that IE 7's isn't tested to pass ACID2.
    • I believe it's been fixed in the Gecko main tree, but
      no released version of Firefox has used it yet.

      Does anyone know what version of Firefox is slated to
      use the corrected Gecko?
    • by mabhatter654 ( 561290 ) on Friday June 23, 2006 @12:19PM (#15590103)
      ACID2 isn't really as important as properly rendering in the first place.. All ACID2 test for is proper handling of improper or edgy code... It doesn't show what good code written to spec is supposed to look like. What's really needed are testing pages that implement one feature at a time for all the browsers to test against. Then add complex pages that include lots of "Real world" interactions to test what it should actually look like.

      The other thing I'd suggest would be Micro-specs... I caught that in another post and I've had a similar idea. Why don't they work with browser makers to "chop up" the specs into point releases that focus on just a few features at a time? The idea of massive specs was cute in theory, but they are just too complex to implement all at once. For instance to get more people up to CSS 2.1, why not create CSS 1.5 that has all the commonly implemented things in it.. then we could at least use that and know everybody had it. The granddaddy of all messed up specs is SVG. That spec needs to be chopped down terribly. It includes tons of stuff nobody really needs and everybody who implements it is at different stages on different features.... Using any 1 implementation is cool.. but for cross-browser work it's terrible. Chop it down to a smaller spec, like opera is going for the mobile implementation because it's so much smaller. then add the extra features like sockets and video and such back in later.

      • by GlassHeart ( 579618 ) on Friday June 23, 2006 @02:07PM (#15591108) Journal
        ACID2 isn't really as important as properly rendering in the first place.. All ACID2 test for is proper handling of improper or edgy code... It doesn't show what good code written to spec is supposed to look like. What's really needed are testing pages that implement one feature at a time for all the browsers to test against.

        ...which is why we have the W3C test suite [w3.org]. Your underestimation of Acid2 is also typical of somebody who has never worked on a browser. One of the worst (it's difficult, tedious, and you feel like a moron doing it) parts of the job is to find out and mimic what IE does with bad markup, because the real world is full of such, so if IE passes Acid2 there will be that much less for everybody else to do. Note also that while it's obviously easy for IE to do whatever it does with a piece of bad markup, trying to remain compatible on a browser with a different parser or renderer may not be easy at all.

        Why don't they work with browser makers to "chop up" the specs into point releases that focus on just a few features at a time?

        Because truly competing browser vendors do not synchronize their development schedules. They pick the features that they think their customers will want most, and implement those first. Eventually, you hope they'll all arrive at CSS 2.1 someday, but they'll get there through different paths.

        Also, each browser is likely to have unique architectural weaknesses that makes it very hard to implement a portion of the spec. While the vendors all know that a substantial rewrite is inevitable, they're not going to do that kind of fix until they're ready to.

      • by Bogtha ( 906264 ) on Friday June 23, 2006 @02:24PM (#15591242)

        All ACID2 test for is proper handling of improper or edgy code... It doesn't show what good code written to spec is supposed to look like.

        Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine [slashdot.org]:

        Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.

        There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?

        It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.

        Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?

      • No standarised/interoperable error handling is what haunts HTML. That's the real-world problem that Acid2 is trying to solve.

        CSS2.1 is the "1.5" you're talking about. RTFA! It removes/changes all features of CSS2 that weren't interoperable in current browsers.

        CSS is modular and can be implemented smaller chunks thanks to back- and forward-compatible error handling (it's not perfect though, but better error handling is considered doomed because of vendors dishonesty/sloppiness)

        You mean chopping SVG li

      • After clicking a few of the CSS3 links in the article, it looks like CSS3 is broken up into modules, which may depend on other modules. I guess then a browser could claim to fully support CSS3 module X even if it does not support all of CSS3.
    • by Zak3056 ( 69287 ) on Friday June 23, 2006 @12:29PM (#15590193) Journal
      Only IE was singled out (of course), but there are not many browsers that pass ACID2...

      Come on, he was responding to the question "If you could make Microsoft do something to IE, what would it be?" That hardly seems an appropriate place to mention other browsers, don't you think?

  • The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate: AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest ADJACS: Asynchronous DOM, JavaScript and CSS ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS AJAHCS: Asynchronous JavaScript, HTML and CSS AJACS: Asynchronous JavaScript, HTML and CSS "GNU/AJAX"? :P
    • > The "AJAX" name sounds great, but allow me to propose a few alternate spellings that I find more accurate:
      > AJACX: Asynchronous JavaScript, CSS and XMLHttpRequest
      > ADJACS: Asynchronous DOM, JavaScript and CSS
      > ADHJACS: Asynchronous DOM, HTML, JavaScript and CSS
      > AJAHCS: Asynchronous JavaScript, HTML and CSS
      > AJACS: Asynchronous JavaScript, HTML and CSS

      "GNU/AJAX"? :P
    • You must use a recursive acronym, like this:

      ADHJACS: ADHJACS Doesn't Help, Just Amplifies Confusion and Silliness

      Good luck with your quest, Don. Say hi to Sancho for me.
  • Great job! (Score:4, Interesting)

    by bcat24 ( 914105 ) on Friday June 23, 2006 @11:22AM (#15589685) Homepage Journal
    Thanks for taking the time to answer my question. The article was definitely an interesting read. Good job, Håkon.

    PS: Why don't you put up a sound clip of how you pronounce your name?
    • Good idea, but it won't help much. Linus did it with Linux and I still here people say "LieNIX" instead of "Linux". I had difficulty pronoucing his name when I got the first edition of CSS: Design for the Web. (great book) Around my friends i just started calling it the Bert and Ernie book. Looking back its not the nicest reference, but it sure did reflect how i felt about the backwards z-index numbering in opera 4. I stopped supporting opera explicitly then and to this day never use it.
  • by pavon ( 30274 ) on Friday June 23, 2006 @11:24AM (#15589717)
    I'm using it right now. Ubuntu on a IBM Thinkpad X41 is the environment I live in. Ubuntu rocks -- especially with Opera on top! (And Emacs right underneath.)

    So you are running Opera on top of Ubuntu and Ubuntu on top of Emacs? That's my kind of Emacs user!

  • Verticality (Score:4, Insightful)

    by Billosaur ( 927319 ) * <wgrother.optonline@net> on Friday June 23, 2006 @11:26AM (#15589726) Journal

    Indeed, the CSS formatting model allows more control horizontally than vertically. This is due to (typically) having a known width, but an unknown height. As such, the height is harder to deal with.

    However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

    That's an interesting point, given the profusion of video monitor sizes and their associated resolutions (800X600, 1024X768, etc.), and the variety of browsers and the explosion of toolbars now available. How do you define "height" in a browser? There's certainly a fixed viewing area based on all the above factors, but it's so varied from user to user that it makes it hard to come up with a good idea of how big something should be on the page. You can use relative sizes, but that only works if the content is scalable; fixed sizes are good for a range of resolutions, but as resolution increases it tends to make things become squashed vertically.

    It's the bane of web development -- how scalable do you make your content? Do you care that much about old browsers and how things render? How many people out there are realistically still using IE4 and Netscape 4?

    • What I generally do when I'm developing a site is this:
      When I first start development, I generally keep everything in plain text with no graphics and no style sheet. Once I'm done with the initial development, I'll go through and add in the CSS and get the layout looking good, but I keep a copy of the old plaintext look. I test to make sure that my design works with the latest browsers. Then I go back and test to see what older browsers display the page properly. If I get to a browser that doesn't rend
  • by Space_Soldier ( 628825 ) <not4_u@hotmail.com> on Friday June 23, 2006 @11:41AM (#15589825)
    I remember watching a Channel9 video. If my memory does not deceive me, Microsoft have 4-6 people working on IE7, and most of their work was to fix bugs, mostly security, and change the interface. With so few resources given to IE after it has been neglected for many years, one cannot expect Microsoft to provide a decent browser. Based on the fixes (CSS, transparent PNG, etc.), IE is moving into the right direction. However, as we all know, they tied it with Windows releases. Assuming that IE8 will be at the same standards support or better than Opera/Firefox and further assuming that the next version of Windows is released 3-5 years after Longhorn (Vista), IE8 is very far away. For a web designer, which I am, IE is a hell. For programmers, think of sending a compiler valid code, and instead of generating the executable properly, it generates rubbish, or it whines that proper syntax is invalid, or it generates 2+2=5.
    • I think it may be up to web developers (me, you, and the other guy) to use the newest standards that are supported by the other browsers (Opera, Firefox, Safari) and to stop supporting IE to any extent other than basic page layouts. I know its often dictated by business to support IE, and you still would be, but not to the extent that it has been. Telling people that a site will be better in a alternate browser may be a good choice in this as well.
  • The Acid Test (Score:2, Informative)

    by dmjones500 ( 781144 )
    The link in the answers seems to be broken. The page can be found here: http://www.webstandards.org/files/acid2/test.html [webstandards.org]
  • However, CSS2 fixed positioning allows you to place content relative to the viewport (which is CSS-speak for window) instead of the document. For example, by setting position: fixed; bottom: 0 on an element, it will stick to the bottom. This works in Opera, Safari and Mozilla-based browsers. IE6 doesn't support it, however. It remains to be seen if IE7 will support it.

    Forgive me if I'm misunderstanding this comment, but I think this fails to solve the common case. Most often, we would like to have a footer

  • by truthsearch ( 249536 ) on Friday June 23, 2006 @12:47PM (#15590387) Homepage Journal
    Good interview, but I have to disagree with this: "The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead."

    Create the best design for the problems at hand and publish specifications. It's up to developers / vendors to implement it at whatever speed they wish. If the monopoly has no incentive to conform to standards there's no reason to wait for them to catch up. The rest of the world can move on and smart users can choose to switch.
    • If the monopoly has no incentive to conform to standards there's no reason to wait for them to catch up. The rest of the world can move on and smart users can choose to switch.

      I *think* his point was that the rest of the world doesn't bother - so there's problems getting too far ahead

      It baffles me why IE is still dominant when it wasn't THAT long ago people were happily changing browsers based on what worked best. I can understand how MS got to the dominant positioning - bundling + decent product (and fo

      • I don't know why it's still so dominant either with so many tech-savvy people promoting firefox to their friends and relatives.

        But back to the standards, I really don't think there's such a thing as "getting too far ahead". A standard is a standard. Implement it if and when you feel like it. Physical things are invented first, then widely used later. If someone comes up with a great idea, write it down and try to get organized group approval. Hopefully someone will later implement it.
        • How long did it take for MS to maximise IE usage?

          There haven't been THAT many people recommending FF to a big enough audience for long enough.

          Besides, Opera is far better. ;)

  • What's with turning pre into an iframe for 3 or 4 characters of scrolling?!
    I mean, if you want to do this in some way to save readers from wide comments,
    fine. But apply a class to the article contents to undo the god-awfulness.
  • Er... there are licensing issues here. Not every TTF file you can get your hands on is licensed for generalized distribution. That's why MS has their embedding format - to respect the copyright of the font creators.
  • If CSS (and SlashDot's use of it) is so
    great, why am I being forced to horizontally
    scroll every one of these questions?
  • It was me who asked about the defintion of pixel. Perhaps I didn't phrase the question well enough. Consider that as screen resolutions improve, a CSS pixel will have to be mapped to two physical pixels on a screen. So simple phrases like "the image is 100 pixels wide" will have two different meanings (depending on "pixel" = physical pixel or "pixel" = CSS pixel). I think that this is needless confusion, and the answer given by Håkon appears to be flippant.
  • I missed the call for questions, and didn't get to ask the following questions. Somebody please keep these in mind for when the topic resurfaces in the future:
    1. Why doesn't CSS allow web designers to specify styles per user agent? I would kill to stop using the stupid "IE doesn't see direct-descendant selectors so let's use that hack to fix IE's box model problems" in my style sheets. Furthermore, this approach inspires programming techniques that can be considered only as abominable. Instead, I'd like
  • by fbg111 ( 529550 ) on Friday June 23, 2006 @04:37PM (#15592352)
    "W3C isn't the bottleneck, browsers are. The dominant browser on the web hasn't been updated for years, and it doesn't make sense for specifications to get too far ahead."

    I tend to disagree. Just b/c MS can't/won't keep up doesn't mean that others can't. Opera and Mozilla are not too far behind the advancing CSS spec, and slowing down for IE will only stunt the other browsers' development. It's like putting the advanced kids in the remedial classes; it helps neither the advanced kids nor the struggling ones.

    In fact, possibly the only way to force IE to update is by advancing the CSS spec at whatever pace is feasible, and as Mozilla, Opera, Safari, etc. implement it, IE is left behind. That's the only reason why MS finally reinstated the IE team to push out IE7, except it was over security concerns rather than platform advancement concerns. Not advancing the spec prevents the other browsers from leaving IE behind, giving MS no reason to upgrade IE.

Hackers of the world, unite!

Working...