171–180 of 180 posts
Interesting trick. But I think adBlockers block requests to entire tracking domains. So even css calls would be blocked?
Earlier quoted context omitted.
As a developer: If we actually pushed browsers to fix things, you wouldn't need to worry about that. Why should the job fall to you to work around their shitty implimentation of the spec?
Because when management asks you why their site that they paid hundreds of thousands of dollars for doesn't work on , your answer can't be "the browser's implementation of the spec is shitty, blame them." Your answer is going to be, "Yeah, sure, let me fix that."
If it's a major browser which management cares about, then you should be testing with it already. If you're not, then logging user agent strings isn't going to help.
Logging user agent strings would help if, for example, an unexpectely-large proportion of users are using a "non-major" browser, in which your site is broken.
If the proportion is small, management won't care.
If the proportion is expected, then market/demographic research is partly to blame; update the spec.
If the browser is "major", you should be testing with it anyway.
If the site isn't broken, there's no problem.
But how many users disable JavaScript in their browser to prevent tracking? And is the fact that a website can track all your clicks and mouse movements a privacy/security issue to begin with? Isn’t it by design that the website you’re visiting can track you?
> by design By design, the web is a "1. send me the document 2. here it is" transaction, not a series of many small notifications. By design, the url() property almost certainly wasn't intended to be dynamic. This is clearly 'bending the established rules' — cleverly, admittedly.
Earlier quoted context omitted.
Right, which is why GA is not allowed to load in my browsers. This is a different avenue for disclosure of a similar bundle of info.
Just curious: Are you okay if it's something self-hosted (like Piwik) doing the same kind of tracking? In other words: Do you not want a third party (like Google) to have that data or the second party (web administrators)?
My primary objection is automated profile-generation and identifier sharing - third parties don't need realtime updates on my reading habits. I like to think folks who run their own analytics aren't sharing identifiers with adtech shops, but of course can't know.
Earlier quoted context omitted.
Yeah, I would just leave that site. But if you implement that feature using known simple and stable, tech, you wont really have that problem. > Remember: incentives. The goal of a web developer is to make sites people use. The goal should be to empower users. Anyone can make a site that people "use"
Does empowering users get the web developer paid? I mean, in an ideal world, of course it does. But again: incentives. Keep in mind: search engines themselves are extremely empowering, and they are not generally considered to be something a person pays directly for.
Earlier quoted context omitted.
Yeah why ask to be empowered to fix your own problems when you could just beg someone else to fix them?
How is a browser not rendering correctly not their problem?
Extreme ownership of problems. It's a really helpful concept. You'll stop trying to blame people all of the time for things that you can control and find solutions for them instead. On top of that, if you can't control it you can let it go as something that you can't fix.
Earlier quoted context omitted.
Because when management asks you why their site that they paid hundreds of thousands of dollars for doesn't work on , your answer can't be "the browser's implementation of the spec is shitty, blame them." Your answer is going to be, "Yeah, sure, let me fix that."
> your answer can't be "the browser's implementation of the spec is shitty, blame them." If it's a major browser which management cares about, then you should be testing with it already. If you're not, then logging user agent strings isn't going to help. Logging user agent strings would help if, for example, an unexpectely-large proportion of users are using a "non-major" browser, in which your site is broken. If the…
Even if Chrome followed the spec to a T, programmers still write bugs. So, I'm not going to expect a browser (at least) 15 versions old to behave perfectly. And we all know that the spec isn't perfectly implemented.
So, no. Unfortunately sometimes there are things that will make management care a lot about a browser that they really shouldn't.
Earlier quoted context omitted.
> your answer can't be "the browser's implementation of the spec is shitty, blame them." If it's a major browser which management cares about, then you should be testing with it already. If you're not, then logging user agent strings isn't going to help. Logging user agent strings would help if, for example, an unexpectely-large proportion of users are using a "non-major" browser, in which your site is broken. If the…
I see what you're saying, but unfortunately, especially in enterprise, the browser version is often locked to something quite old. One of our clients has locked to Chrome 48. Even if Chrome followed the spec to a T, programmers still write bugs. So, I'm not going to expect a browser (at least) 15 versions old to behave perfectly. And we all know that the spec isn't perfectly implemented. So, no. Unfortunately sometim…
I never said management should or shouldn't care about this or that browser. I never said anything about browsers being new or old.
I said that developers should be testing with whatever browsers management cares about. If management care about it, and there's some justification, then add it to the spec.
> unfortunately, especially in enterprise, the browser version is often locked to something quite old. One of our clients has locked to Chrome 48.
That's an excellent justification for having Chrome 48 compatibility as part of the spec, so you should already be testing your sites with it. What has that got to do with user agent strings?
Is Chrome 48 even old? I tend to ensure IE6 compatibility, unless I have a good reason otherwise (e.g. voice calls over WebRTC, or something). When I'm using w3m, e.g. to read documentation inside Emacs, I occasionally play around with my sites to ensure they still degrade gracefully.
Earlier quoted context omitted.
> So what, the site could route you through a server side proxy anyways There's little interest in proxying through a token system (this would require a DB read at each click, and a DB write at each page generation), which means the actual link is available client-side and the whole thing can be bypassed.
It's easy to design a system like this where the actual link isn't available client-side, and the server doesn't need to wait on a DB read and write before responding to the client: make the URL parameter be the destination URL encrypted so that only the server can read it. That kills the need for a DB read. Then the server can respond to the request before the DB write finishes since the integrity/consistency of tha…
Earlier quoted context omitted.
How is a browser not rendering correctly not their problem?
Who said it's not their problem? But it's also relying on someone else to fix something that you could fix. If I need to get somewhere it doesn't matter if my car's engine is broken because the company stabbed it with bolts I just need a working car. I can sit around whining about how awful the car company is but it doesn't get shit done fast. Extreme ownership of problems. It's a really helpful concept. You'll stop…
If you need your car to be reliable, don't bolt experimental features onto it, and test it before you need to take it on the road.