Should UA string spoofing be treated as a trademark violation?

R

Randy Webb

VK said the following on 4/22/2006 8:52 AM:
Ref. Should UA string spoofing be treated as a trademark violation?

As a support for my point of view expressed in this thread, where Opera
was mentioned among the most "nasty offenders". Either they read this
and agreed on it, or they came to the same conclusion independently,
but:

You can rest assured they didn't change it based on this thread.
<http://www.opera.com/docs/changelogs/windows/900b1/> (freshly listed
on opera.com):

Changelog : HTTP
....
Changed default UserAgent string to identify as Opera.
....

P.S. Now it's time to take care of Safari and Konqueror ;-)

No, it's time to stop browser detecting, object detecting instead, and
then it is a moot issue *what* the UA string says.
 
M

Matt Kruse

Randy said:
No, it's time to stop browser detecting, object detecting instead, and
then it is a moot issue *what* the UA string says.

I raised a point in this thread to answer Richard's request for examples of
cases where browser sniffing would ever be needed. No one replied. I think
there are cases where browser sniffing is justified, even if not completely
accurate. I'd like to be proven wrong ;)
 
V

VK

Matt said:
I raised a point in this thread to answer Richard's request for examples of
cases where browser sniffing would ever be needed. No one replied. I think
there are cases where browser sniffing is justified, even if not completely
accurate. I'd like to be proven wrong ;)

I gave you some already. And for IFRAME also if you want to cover that
AOL Browser without conditional comments support.

But it is just a play-bye. What about XSLT documents? For browsers
(Firefox, Camino, Opera 9.0a or higher, Safari 2.1 or higher, IE 6 or
higher) I want to serve normal .xml data for client-side
transformation. For sub-standard crap it is needed to say at least some
condolensences - in HTML.

Or even someone got shifted on the XHTML basis: wouldn't it be nice to
serve to XHTML happily unaware browsers "text/html" instead of
"application/xtml+xml" ?

There are other cases (how many do you need? :)
 
R

Richard Cornford

Matt said:
I raised a point in this thread to answer Richard's request
for examples of cases where browser sniffing would ever be
needed. No one replied.

Probably in part because we have discussed the subject before and your
re-raising the same question implies that you were not interested in the
responses you got last time:-

1. As the issue applies to all Windows browsers that employ the native
Windows select GUI component to represent HTML select elements the
problem has nothing to do with IE as such but instead determining
whether the particular UA is using that component. Which may be
detectable in some environments as that component is notorious for not
accepting particular CSS assignments and its refusal to accept them may
have manifestations in the DOM.

2. It is only worth considering not using the IFRAME even when it is not
necessary if its use is harmful, and branching in the creation of the
IFRAME also means having two sets of, for example, positioning code. It
may be simpler to just employ the IFRAME anyway. And having done that
you will have a generally available hidden IFRAME on hand for doing
asynchronous background loading; see it as an opportunity rather than a
problem.

3. The IFRAME shim is not the only technique for handling the burn
through issue.
I think there are cases where browser sniffing is justified,
even if not completely accurate. I'd like to be proven wrong ;)

Trying to justify something that doesn't work (to the extent of being
catastrophically wrong in worst cases) is hardly a reasonable response
to finding that the more reliable alternative cannot cover 100% of
cases.

Richard.
 
M

Matt Kruse

Richard said:
Probably in part because we have discussed the subject before and your
re-raising the same question implies that you were not interested in
the responses you got last time:-

I've not seen previous replies on the topic.
1. As the issue applies to all Windows browsers that employ the native
Windows select GUI component to represent HTML select elements

I'm not sure that is true. A browser could easily be written in Windows
using native controls which do not overlap other objects in the page. It is
merely a side-effect of bad programming in IE that is at fault.
the
problem has nothing to do with IE as such but instead determining
whether the particular UA is using that component.

I believe that is a false statement.
Which may be
detectable in some environments as that component is notorious for not
accepting particular CSS assignments and its refusal to accept them
may have manifestations in the DOM.

But that is a case where you are testing one feature and then inferring
another.
2. It is only worth considering not using the IFRAME even when it is
not necessary if its use is harmful

It cannot be assumed that there is no browser where using the iframe would
be a problem, but it would probably be a safe assumption AFAIK.
3. The IFRAME shim is not the only technique for handling the burn
through issue.

True, but it seems to be the best, IMO.
Trying to justify something that doesn't work (to the extent of being
catastrophically wrong in worst cases) is hardly a reasonable response
to finding that the more reliable alternative cannot cover 100% of
cases.

I'm talking only about the cases which cannot be covered by the more
reliable alternative.
 
V

VK

Matt said:
I'm not sure that is true. A browser could easily be written in Windows
using native controls which do not overlap other objects in the page. It is
merely a side-effect of bad programming in IE that is at fault.

"Super Z of form elements" (now called "firing through" I guess) is an
age old problem first introduced with DHTML itself. It was common for
both NN 4.x and IE 4.x. Later fixed in IE 5.2, reintroduced in IE 5.5,
fixed, reintroduced - so the same version line might have it or not
depending on the minor version.

The core issue here is that systemwise form elements (in Windows at
least) are not parts of the page graphics context. They are graphics
peers painted separately atop of the page context and anchored to the
indicated page points. The closest analogy would be a transparent touch
screen with form elements painted and placed atop of your monitor
screen. One can reveal this "hidden misery" by making a big element
reach form and scrolling it on a slow machine. You'll see form elements
being late from the page content itself (labels, text, graphics etc.)
and then "jumping" all together to the new position.

Thus in order to let a page content to be atop of a form element, the
only way is to "place another touch screen atop of the existing one".
Until DirectX got mature it was simply impossible - and even now it is
a tricky task.

Personally I hate Super Z issue, and it was a headache since 1998 for
everyone. And I really thing that in so many years IE should switch
long ago on build-in DHTML widgets instead of torturing the legacy
peers with DirectX. But I may not know all issues.
 
M

Michael Winter

On 24/04/2006 02:16, Warren Sarle wrote:

[snip]
How would you use object detecting to:

1) find out whether onunload fires when you hit the back, forward, or
reload buttons, or close the browser window?

One wouldn't nor should one care. The unload event shouldn't be used for
anything important, anyway, so it's not a big deal if it fails to fire.

[snip]
2) find out what colors an inset, outset, ridge, or groove border
actually uses when you specify a border color of #000000?

One wouldn't as it's a minor presentational issue, and unrelated to
browser scripting.

If black looks good in one browser, but not another, try a compromise. A
dark grey will probably do just as well for the former, and be enough to
adjust the secondary colour chosen by the latter.

[snip]

Mike
 
T

Thomas 'PointedEars' Lahn

Warren said:
"Randy Webb" [...] wrote [...]
No, it's time to stop browser detecting, object detecting instead, and
then it is a moot issue *what* the UA string says.

How would you use object detecting to:

1) find out whether onunload fires when you hit the back, forward, or
reload buttons, or close the browser window? (Onunload does not work in
those cases in Opera and, I have been told, in Safari, but it works in
many other browsers.)

You don't, instead you want to reconsider your application design then.
(This has been discussed before here, search the archives.) However, if
`onunload' is to be used, you detect whether it works if you place some
code in it. You are out of luck without script language support, though.
2) find out what colors an inset, outset, ridge, or groove border actually
uses when you specify a border color of #000000?

You are asking the wrong question.

1. `inset', `outset', `ridge', `groove' and a color value are mutually
exclusive for the `border' property. One should not attempt to set
both of them in the first place.

<URL:http://www.w3.org/TR/REC-CSS2/box.html#value-def-border-style>

2. You could retrieve the computed style. You are out of luck without
script language or DOM support, though. [For example, the computed
color of "inset" etc. does not work for borders in Firefox;
.getPropertyValue("border-bottom-color") always yields "rgb(0, 0, 0)"
then.]

3. There are more factors to style than the browser name or version.
For example, every graphical Web browser runs on top of a graphical
framework that can define its own color scheme.

4. With !important rules in the user stylesheet, the user can superimpose
what he wants over your author stylesheet.

5. The `inset' etc. `border' property values are exactly there for you
_not_ to care about the colors of the user interface, but to leave it
the way the user wants it (set it up), according to the `color'
property of the element.
(The actual colors vary from black to light gray in various browsers.)

Due to the above facts, they vary much more than you think.


PointedEars
 
R

Randy Webb

Matt Kruse said the following on 4/23/2006 12:20 PM:
I raised a point in this thread to answer Richard's request for examples of
cases where browser sniffing would ever be needed. No one replied. I think
there are cases where browser sniffing is justified, even if not completely
accurate. I'd like to be proven wrong ;)

I read it, and didn't reply, because I have never had need to deal with
the issue. IFrames and Select lists being windowed in IE is what I read
you referring to and I have never had a problem with it. It's the way it
is and I won't use a crutch to try to force something around it.

I do know of one situation where browser detection *might* be needed and
that is with the AOL Browser but nothing comes to mind other than
window.external. The browser it uses is the default IE but it's only a
shell of it. Never dug real deep into it to see what else it blocks from
the original IE though.
 
R

Randy Webb

VK said the following on 4/24/2006 5:03 AM:
"Super Z of form elements" (now called "firing through" I guess) is an
age old problem first introduced with DHTML itself. It was common for
both NN 4.x and IE 4.x. Later fixed in IE 5.2, reintroduced in IE 5.5,
fixed, reintroduced - so the same version line might have it or not
depending on the minor version.

"Super Z"? Are you trying to create new terms?

The problem comes when you try to do something that the browser does
differently and you start trying to change the default behavior.
 
R

Randy Webb

Warren Sarle said the following on 4/23/2006 9:16 PM:
How would you use object detecting to:

1) find out whether onunload fires when you hit the back, forward, or reload
buttons, or close the browser window? (Onunload does not work in those
cases in Opera and, I have been told, in Safari, but it works in many other
browsers.)

I wouldn't as you are solving the wrong problem. If you need to use
onunload for anything, its too late and the problem is somewhere else.
2) find out what colors an inset, outset, ridge, or groove border actually
uses when you specify a border color of #000000? (The actual colors vary
from black to light gray in various browsers.)

It uses #000000 but what the user sees will depend on the settings of
the OS and/or browser. But, what difference does it make? Again, it is
solving the wrong problem. It reeks of the "pixel perfect" layout
problem where you want "color perfection" across browsers and it isn't
going to happen.
 
V

VK

Randy said:
"Super Z"? Are you trying to create new terms?

No, just using the old one (as I mentioned). But if one likes "firing
through" better then it's totally fine - it is descriptive enough.
 
M

Matt Kruse

VK said:
No, just using the old one (as I mentioned). But if one likes "firing
through" better then it's totally fine - it is descriptive enough.

I've never heard of either term. We must run in different circles.
 
V

VK

Randy said:
Matt Kruse said the following on 4/24/2006 1:19 PM:

VK's circle is square though :)

Guys, you may call it even "foobar effect" if you like. As no name of
Array is involved here, I'm very relaxed :)

firing through, firing through, firing through... OK, I'll remember
now. Doesn't change the reason of this graphics glitch though - nor its
presence in some environments.
 
R

Randy Webb

VK said the following on 4/24/2006 2:38 PM:
Guys, you may call it even "foobar effect" if you like. As no name of
Array is involved here, I'm very relaxed :)

firing through, firing through, firing through... OK, I'll remember
now. Doesn't change the reason of this graphics glitch though - nor its
presence in some environments.

Who said it was a "glitch" though? It works/behaves exactly like it was
intended to do. It may be undesirable effects but it's not a glitch :)
 
V

VK

VK said:
firing through, firing through, firing through... OK, I'll remember
now.

.... despite it is kind of misleading for the effect nature: it implies
that your DHTML *is* on the top but a nasty form element is firing
through it. Technically it is just opposite: form elements are always
on the very top, on its own rendering layer, and your DHTML is sliding
below it. This is why even z-index:1000 doesn't help - because it's
still z-index of the page's rendering layer. The only way is to add the
3rd rendering layer atop of both and do stuff there (window, iframe).
So the older term is better IMHO.

firing through, firing through, firing through... I remember.
 
W

Warren Sarle

You are asking the wrong question.

1. `inset', `outset', `ridge', `groove' and a color value are mutually
exclusive for the `border' property. One should not attempt to set
both of them in the first place.

<URL:http://www.w3.org/TR/REC-CSS2/box.html#value-def-border-style>

I see no such statement about mutual exclusion in the cited document.
In fact, the inset, outset, ridge, and groove border-styles do work in
combination with border-color in IE, Firefox, Opera, and Safari, but
the results are strikingly different.

5. The `inset' etc. `border' property values are exactly there for you
_not_ to care about the colors of the user interface, but to leave it
the way the user wants it (set it up), according to the `color'
property of the element.

In the application I am working on, the _users_ _want_ the page to
employ several easily-discriminable border colors as important visual
cues, and they don't think that solid borders are pleasing to the eye.
 
T

Thomas 'PointedEars' Lahn

Warren said:
I see no such statement about mutual exclusion in the cited document.

It is not a syntactical, but a semantical exclusion:

| The color of borders drawn for values of 'groove', 'ridge', 'inset',
| and 'outset' depends on the element's 'color' property.

There will be change in CSS 2.1, which is said to be the errata to CSS2 when
both versions differ:

,-<URL:http://www.w3.org/TR/CSS21/box.html#value-def-border-style>
|
| [...] The color of borders drawn for values of 'groove', 'ridge', 'inset',
| and 'outset' depends on the element's border color properties, but UAs
| may choose their own algorithm to calculate the actual colors used. For
| instance, if the 'border-color' has the value 'silver', then a UA could
| use a gradient of colors from white to dark gray to indicate a sloping
| border.

Of course that is only emphasizing what was said before: you cannot rely
on anything here.
In fact, the inset, outset, ridge, and groove border-styles do work in
combination with border-color in IE, Firefox, Opera, and Safari, but
the results are strikingly different.

It should be clear now that consistent results cannot be expected regarding
this.
In the application I am working on, the _users_ _want_ the page to
employ several easily-discriminable border colors as important visual
cues, and they don't think that solid borders are pleasing to the eye.

Well, it is your job either to point out the limitations of a Web
application to your client, or to come up with an application design
that does not have these limitations. Sacrificing interoperability,
for example, you could use ActiveX/COM controls or XUL that may have
better options when it comes to UI layout.


PointedEars
 
W

Warren Sarle

...
Well, it is your job either to point out the limitations of a Web
application to your client, or to come up with an application design
that does not have these limitations.

I _have_ come up with an application design that works on half a dozen
current browsers by means of browser detection. My original question was
in response to a claim--often repeated in this news group--that one
should use object/feature detection instead of browser detection. And
indeed I would prefer to use object/feature detection if that were
possible. Judging from the replies so far, it is not possible.
 

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top