Samuel Sidler wrote:
> Camino's not changing the Mozilla project's view of browser sniffing. 
> Not in any way should this be misinterpreted to mean that any Camino 
> team member believes those ideals aren't true.

"These are my principles. If you don't like them, I have others"?

There's no point having ideals if you abandon them in practice; you are 
just showing they aren't actually your ideals.

You can disagree with the project's policy if you like; but you can't 
both agree with it and propose what you are proposing.

> Camino is a mozilla.org project, yes, but it's also it's own project 
> with it's own rules and it's own UA that can be changed at will (see my 
> comments on the spec below) by the Camino team.

I think that the collision of "Camino is a mozilla.org project" and 
"Camino is its own project" is what has led to this debate. Exactly 
where the UA string falls in that is the question at hand.

>> - Is it OK if a site warns you that your browser has not been tested, 
>> but allows you to continue anyway?
> 
> My answer would be "hell no". There is no way it's OK. Maybe it is for 
> you, but for end-users, this experience sucks. I think (hope) we can all 
> agree with that.

Why so, if it's the truth? Camino is not Firefox - you would be the 
first to admit that - and so it's possible that there will be things 
that work in Firefox but don't in Camino. Perhaps you have come across 
them yourselves in your bug fixing.

>> - What about sites (e.g. banks) for which lack of support for Camino 
>> is a deliberate policy?
> 
> Until we try it, as the bug mentions, we have no way of knowing what 
> portion of the web legitimately blocks Camino. 

I don't understand how your point follows from my question. I was 
talking about banks who have specifically told us they are blocking 
Camino - no UA string change is required to find this out.

How does changing the UA help you distinguish between a legitimate and 
an illegitimate block?

>> We have a specification for user agent strings:
>> http://www.mozilla.org/build/revised-user-agent-strings.html
> 
> The proposal that currently exists follows the spec and I doubt any 
> Camino team member wants to violate that spec. 

I didn't imply that it didn't; I linked to it, if anything, to show that 
it didn't.

> (Note that other browsers *have* violated the spec. See comment 22 of 
> bug 384721.)

If those other browsers are not part of the Mozilla project (again, the 
same question arises), then their behaviour cannot be something we worry 
about.

> The true issue above is that web developers aren't looking for Gecko. 

Sorry, but that's rubbish. If all we have are 29 sites which are broken, 
then the fact is that the vast majority of web developers _are_. Find 
any of the new DHTML Ajax libraries, used to build hundreds of sites. 
They all check for Gecko, and I assume they work fine in Camino.

> One idea is to rethink the idea of a user-agent string. What information 
> in a UA is actually important? If we want web developers to check based 
> on the Gecko rv in the UA instead of the product name, why do we ship 
> the product name in the UA at all? 

That's a very, very good question.

> I can see marketing reasons (market 
> share, etc), but are there technical ones? 

If people want to judge market share, we can make sure that each release 
we do has a slightly unique Gecko date (a day apart or whatever). Then 
stats people can distinguish, although most people won't care. Because 
the date would change with every sub-release, people would never look 
for specific dates for sniffing purposes. They could still do >=, but 
we're fine with that.

> (Note that the idea above would require us to either break or modify the 
> user-agent string specification, which I fully understand.)

Hey, we wrote it :-) Of course, there's parsing code out there. So we 
need to be careful. But with warning, we might be able to come up with 
something.

Gerv
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout

Reply via email to