On Thu, 09 Oct 2008 12:46:10 +0200 Came this utterance fomulated by Ingo Chao to my mailbox:
Thanks for your useful reply > > The debate about hacking is mostly about hacking IE lte 7. We have > sufficient methods to hack IE, though. Because of its market share, we > have the knowledge about the bugs, the filtering methods and the > workarounds for IE. > > I don't think we need filtering techniques for current "compliant" > engines like Gecko, WebKit, Opera, and probably IE8. I know they have > their bugs too, but for most everyday coding problems, there are > interoperable methods available. The differences that these browsers > show are the difficulties in interpreting a specification that is > still fine-tuning on edge-cases. Now is pretty good yes, but: http://www.andybudd.com/archives/2005/11/common_css_bugs_in_safari_firefox_and_opera/ which is a little out of date but http://www.quirksmode.org/bugreports/index.html Dont forget how hard it is to make a large program 100% error free. http://portal.acm.org/citation.cfm?id=948586 None of us have a crystal ball on the future. Browsers are mostly becoming very compliant now (lack of SVG support in IE is a biggie in my eyes, now that MSFT is going CSS 2.1). But bugs and differences in interpretation will occur, no crystal ball will see by how much. Some developers will take advantage of the current/upcoming browser frenzy to develop bleeding edge CSS. Why deny them a tool which may be usefull. The implementers may start moving ahead of standards with their own features(-moz-opacity). > Any static filtering method for these browsers under active > development would fail sooner or later, so any hack could suddenly > become the problem it should initially solve. Precisely, "any hack" including the Tan Hack. What i am suggesting is theoretically a controlled standards driven hack. As such it is less likely to become a problem. Anyone working at the levels which necessitate such hacks is also likely to test against browser revisions as they come out to establish when a hack is no longer required. Typically we would be looking at one or two lines of code that need changing per web site per hack. I genuinely doubt that Joe NVuUser is likely to concern himself with CSS (or css-d) unless he is learning and growing in the field. > And other filtering methods, on the engine's version level or the > spec's version level, would quickly surpass the abilities of web > authors in following the latest discussions on the specification, to > decide whether a browser is right or wrong. * Download new browser version * View Site * Update CSS if required Pretty much the same process we will all be going through with IE8, and have just gone through with FF3. Standard site maintenance? > A layout should tolerate imprecision by the browser, as it should > tolerate user settings and needs that differ from the author's > settings and needs. The latter is the bigger problem. Agreed; usability, readability, SEO and accessibilty over pretty, tight, inflexible graphic design. This is all good stuff. And no doubt i am going to trip myself up with my own inexperience. But the continued discussion is valuable. -- Michael All shall be well, and all shall be well, and all manner of things shall be well - Julian of Norwich 1342 - 1416 ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
