Sent by Gunlaug_Sørtun on 18 May 2009 11:11
Alan Gresley wrote:
> This part of the hack,
> causes a parsing error. Is this fixed in Firefox 3.5b4? I must admit
> that your hackery (possibly combining structural pseudo class support
> and parsing errors) is hackier than mine. :-)
I'm not surprised :-)
However, keep in mind that I only test hacks to check progress and see
what one can get away with in various browser versions. I do not use
hacks for anything serious.
Also: validity is not an issue (for me) in such test-stylesheets.
> Does Firefox 3.5b4 now send those images above the text line?
> The same test case but with your hack.
I usually don't check what's on such bug lists unless I run into a
specific bug in a real-world case, so I have no idea what the status is
for those bugs in latest versions of affected browsers.
Those who utilize bugs in relatively new browsers for anything serious,
will have to check and update every time a new version is released --
not only the browser they try to target but nearly all browsers. There
are 4 major engines one has to keep track of, and one has to check at
least the last 2-3 generations/versions of each. There are also between
25 and 30 individual browsers that use these 4 engines, and many lag one
or more generations/versions behind the major browser on each engine.
Staying on top of all these while trying to target/hack individual
versions, should keep any web developer busy. If one wants to use ones
time for something else, one better not enter such a hacking-race in the
Testing browsers, with hacks and all, in ways/places where it doesn't
hurt no matter the outcome, is of course an entirely different matter.
That's what I do...
....and I focus on engine versions, not individual, "named", browsers.
For each major or minor modification to my browser targeting stylesheet...
....I also test in at least two dozen browsers with engines that may be
affected because they share bugs and/or proprietary selectors, and a
dozen or so more that simply may not be "shielded" well enough.
The need to provide extra shielding for non-targeted browsers, is the
main reason my selector-chains are so complex and often contain
nonsensical and "unnecessary" parts.
Hackers who check only in a few browsers, tend to produce what looks
like "cleaner" hacks, but such "clean" hacks tend to fail more often and
end up hurting the wrong browsers. Failing hacks on regular web sites do
at least as much damage for developers and end-users as all browser bugs
put together, so one really shouldn't hack if one can't test the outcome
in nearly all 25-30 browsers that are in use today, _and_ also make sure
future (not yet released) versions are somewhat shielded.
The latter means thorough testing in all new beta and RC versions, so
one can keep track of progress and regress and be prepared for the final
releases. Of course; no one in his right mind will hack a beta or RC
version for real, so the purpose for beta/RC testing here is to make
sure hacks meant for older versions won't disturb new versions.
Those who want to can then check bug lists and report problems/bugs
found during beta/RC testing. Such reports are usually "most welcome"
for all browsers.
To see, and eventually test, which hacks (selector chains) that hit the
various versions, look at my page and stylesheet linked to above.
Haven't checked and updated my browser targeting stylesheet in any
detail since March this year, but it still seems to select the right
engine versions across the board - including [Mozilla/5.0 (Windows; U;
Windows NT 6.0; en-US; rv:1.9.1b4)], so I'm in no hurry. Got other
things on my mind these days, and complete and proper testing is time
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/