| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Comments:
<0> Zeros: oh jesus
<1> missing namespaces and such
<2> mattmcc: Of course, you don't have to browser sniff in a way that's guaranteed to break all the time.
<3> webben: are there any other ways?
<4> webben: What specifications? :) There are no rules governing UA strings.
<0> Zeros: what i don't get about this, is it looks liek you can use any RDF cl*** to help describe any other RDF cl***
<1> use conditional comments
<2> Windrose: Of course.
<4> What other ways? You want to rely on JS, now? :)
<1> let the client handle the conditional processing since the UA _knows_ what it is
<1> :P
<3> webben: how?
<2> mattmcc: My reading of the HTTP 1.1 spec would suggest that ID spoofing is quite wrong.
<2> Windrose: Depends on the particular case.
<2> Windrose: On what exactly one's trying to accomplish.
<1> mattmcc, ie/mac had more standards support yeah, but it also had far more "wtf" bugs, and really bizarre issues
<1> IE6 was more consistent in its failures
<3> webben: not really. There is only ONE way of getting the "who" information from an UA - the User-Agent string. There /are no other/ ways, reliable or not.
<2> Windrose: The "who" is irrelevant. It's not the information one is after.
<3> webben: but it's the only information you'll get.
<2> Windrose: Not really. You can learn a lot about feature sets by following the specs and looking at the headers as whole.
<3> webben: but that's not browser sniffing.
<4> Sounds like a lot of inference to me.
<2> Windrose: Well, I guess it depends on how loosely you define "browser sniffing".
<2> Windrose: Browser sniffing is fairly pointless. There may sometimes be some point in sniffing for libraries.
<4> Well, wasn't the reason browser sniffing came up the matter of serving content to IE so that it'll render properly?
<3> webben: I don't. I define it precisely as "figuring out WHICH browser it is". Using the accept header to determining what content it can handle comes into an entirely different category. An abused one, I might add.
<2> mattmcc: Yes, but you don't need to sniff *for* IE to do that.
<2> mattmcc: especially as IE isn't one's only problem.
<4> Indeed. Maybe now you're seeing why I consider the whole practice to be folly.
<2> Windrose: Well, in that case, there's rarely much advantage to be gain from knowing what browser it is. It verges on being irrelevant information.
<3> webben: ... yes?
<2> My point was that one can serve different content to different UAs, not that has to depend on the UA string still less on browser sniffing proper.
<2> The UA string can be taken into account, as per the spec, but it's only one factor, and usually a minor one.
<2> It's also worth noting that the major incentive to ID spoof was in fact 1) to gain access to sites locking people out on the basis of UA string and 2) to declare IE had the same featureset as Netscape.
<2> In the case of 2) the real identity of the browser is irrelevant.
<2> And 1) just sounds like a bad practice.
<5> son of a bitch must pay. it's zend framwork what's nuking my _POST array. i had a feeling.
<5> Zend_Filter, you bastard you.
<4> And then there's stuff like 'personal firewalls' which often casually rewrite UA strings for no good reason. The browser isn't even aware of it.
<2> Did anyone look at my eth/thin space page?
<2> I ran across the issue while looking at fogdo in firefox.
<3> webben: hm?
<2> On my system the thin spaces get turned into eths for some reason.
<2> But only on Firefox.
<3> Into ... 'eths'?
<2> Yes U+00F0 .
<2> An old english letter.
<3> No idea what you mean, sorry. I've used the   entity, that's all I can tell you.
<2> Windrose: Yeah, you haven't done anything wrong AFAIT.
<2> What I'm saying is it's not being rendered as thin space.
<2> Sticking "Arial Unicode MS" in font-family seems to fix it for some reason.
<2> But I put up my test page to see if other people's system did the same thing/
<2> mattmcc: Well, there are also transcoders which will mess up your delivered character set, but what can you do.
<4> webben: Make up a new version and cross your fingers and say "I know everybody will implement it right _this_ time, even though they've never done it right yet!"
<4> Which seems to be the chant of a lot of XHTML advocates.
<3> mattmcc: or "lets create a system so that EVERYONE can make their own languages. That'll solve all the problems with the extendocrap people have added over the years!"
<2> mattmcc: I'm not particularly won over by the argument that it will be poorly implemented. Isn't the poverty of implementation an equally good argument for using plain text instead of HTML wherever possible?
<6> hey
<0> Windrose: .. isnt that xml?
<3> hax: bravo.
<6> a picture taken by a digital camera can have what ratio?
<2> At least plain text doesn't pretend to semantics it largely doesn't possess.
<0> Windrose: sorry, i think i joined this one late
<0> heh
<4> webben: Heh. Fair point.
<7> Can I get an invite to join Gmail from anyone that has an account there?
<4> With that, I'm going to go shoot pool now.
<3> webben: it doesn't posess any. Highly inaccessible.
<3> mattmcc: have fun :)
<0> Co2: that's so 3 years ago
<2> Windrose: What's inaccessible about Gutenberg plain text that isn't inaccessible about the majority of tag soup?
<2> Isn't HTML as written by authors who don't understand (as you put it) the difference between <br /><br /> and </p> more highly inaccessible in a way
<2> since UAs are invited to read in meaning that is actually incorrect.
<2> I mean I agree HTML offers all the theoretical advantages in the world; but most of them aren't realized in practice.
<3> webben: there /is/ no semantics in plain text. It doesn't matter how clever an UA you have - there is nothing there to interpret. That's the entire idea of a markup language.
<2> Windrose: Yes, I guess what I'm saying is that without better tools, m*** markup languages are intrinsically broken compared to plain text.
<3> webben: there isn't any in badly written HTML either, but that doesn't mean we should create a number of NEW ways of badly write documents.
<3> "to badly write"
<2> Windrose: Depends on the tools we create.
<1> arg, why is it that the SQL standard requires such different syntax for INSERT and UPDATE :/
<1> only MySQL has the sane approach to allow a consistent query format
<3> The idea that "There are soo poor tools that people write bad HTML or add badly consceived new tags so we'll instead make NEW languages - without the tools - which makes it easier for them to, ah, write crap" isn't convincing.
<3> Zeros: you want the ENTIRE relational algebra reason?
<1> yes, I want to know why I can't do INSERT INTO user foo = 'bar', baz = 'bam'
<2> Windrose: I'm not saying that the lack of tools is an argument for XHTML. I'm saying that only by having better tools can we ever hope to reap the sort of advantages you're looking for from m*** markup languages.
<1> thats ridiculous
<3> webben: we've spent 16 years developing poor tools for handling something as simple as HTML.
<3> webben: how many years do you think we'll spend creating /good/ tools for something like XML?
<2> Windrose: Like I say, I think it's simplicity has been a bit of an Achilles heel in that respect.
<3> webben: I don't agree. The simplicity is what made it work - and what COULD have made it work better. Now we are back to the mentality - people simply /don't get it/. Making it more complicated doesn't solve that.
<1> Windrose, that means that if I need to do an UPDATE and an INSERT on a table with 10 columns, I have to type out not only a query in INSERT INTO foo (field...) VALUES () but also as UPDATE foo SET field = ?, ...
<2> Windrose: Well, I think with accessibility gradually becoming a legal requirement and (re?)gaining mindshare, and with the growing complexity of web markup (which has little or nothing to do with XHTML), the tools will become more obviously necessary.
<1> if it was consistent I could just change the first damn line
<2> Windrose: If people don't get it, what makes you think a web markup standard is worthwhile?
<0> i think Flash is going ot be what saves us all
<2> Windrose: What makes you think people will ever get it?
<2> I think *that's* far less likely than the creation of decent tools.
<0> see, all the people writing bad HTML now... they're all starting to just develop in Flash, because it looks better, and its "what people want", or so i'm told
<0> so if we can all the bad HTML coders to move to Flash
<1> hax, it just may be, Flash has been moving in the right direction
<2> Windrose: It might be an argument for a radical feature reduction of HTML.
<1> all we need now is a better licensing scheme for it
<1> :P
<0> Zeros: flash is not a good way to present data
<2> Windrose: Where one picked say, three key accessibility features (headings? perhaps) + hyperlinks and *only* used those.
<0> Zeros: my point is that i'd rather have bad flash designers than bad 'html designers'
<0> Zeros: atleast thats a workable problem
<2> Windrose: But then that web would bear little relation to the complex and messy web we have today.
<1> hax, Flash is fine for creating an UI, and Flex is way more sane that HTML/CSS in terms of laying out content
<0> Zeros: only visually
<1> well the same is true of pretty much all UIs though
<1> do you think Firefox's UI is good for a blind person?
<0> i don't really see your point
<1> you're saying flash is only good for visual representation of content
<0> not really
<1> then what did you mean? :)
<0> Zeros: what i'm saying is that if people who can't write documents for the web are going to try... it's better for them to try in Flash
<3> webben: I /don't/ think people will get it. I gave up on the idea about six years ago.
<1> hax, ah
<1> why do you think that though?
<0> Zeros: that reduces the amount of bad html
<1> and increases the amount of pages that are inaccessible to search engines
<0> Zeros: exactly
<1> and screen readers, et al.
<0> Zeros: and if those people want to address those concerns
<0> they need to learn to write good HTML
<1> (yes flash can be accessible, but we're ***uming someone who can't write good HTML wouldn't know how to do that)
<3> Zeros: Flash can be accessible under certain /very/ strict circumstances.
<3> It isn't even /close/ to universally so.
<1> true, but its decent
<3> We'll have to differ on THAT, then.
<1> Flex provides textual representations of the base controls for screen readers automatically
<2> Zeros: Depends. I've only done a tiny bit of playing around with Flash. But I bet you the manuals and guides for Flash are easier to grapple with than WCAG.
<1> and provides a framework for adding them to your own controls
<0> Zeros: atleast if we had people designing bad flash sites, and some point it'd become clear why that's a bad idea
<0> Zeros: and because the lacking features are the same features people don't know how to use in HTML
<0> Zeros: the only reason they'd be learning html is to learn those features
<2> Windrose: Well, isn't the whole debate about which markup to use irrelevant if you don't think people will ever know how to use or ever have the tools to do so?
<0> and then we have people writing good html
<2> s/use/use it properly
<1> Windrose, http://www.adobe.com/macromedia/accessibility/features/flex/best_practices.html
<0> Zeros: see where i'm going with that?
<1> yeah
<1> but there's no way to enforce that
<0> you wouldn't have to
<1> Flash throws compiler errors when your code ****s
<0> we just need to promote flash
<0> heh
<0> Zeros: if these people are like "we need a website", and we're like "make it in flash"
Return to
#web
or
Go to some related
logs:
#web
bazooka asg
i think it's a bunch of bullshit morrison
leetometer wow
#perl
ti-84 ubuntu
#perl
XML::RSS::Parser parse_uri
nvidia GLXBadDrawable
aticonfig: Writing to 'xorg.conf' failed. Bad file descriptor.
|
|