Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

361–362 of 362 posts

Re: Google is killing the open web, part 2

#361

Post by svieira »

akerl_ wrote: post #360
svieira wrote: post #359

Earlier quoted context omitted.

Flash was a plugin to the browser ecosystem that no one ever made a commitment to other than "here it is". SSLv2 and v3 all are protocol versions that anyone can still support, and removing support for them breaks certain web properties. This is less of a problem because the implementations of the protocol are themselves time-limited (you can't get an SSL certificate that is valid until the heat death of the universe…

It’s interesting that you are trying really really hard to explain away every counter example. C’est la vie, I suppose.

Yes, I'm trying to explain my position so that you can understand it. Which I am not doing very well.

Chacun son truc, I believe as there isn't a moral component to this on per se.

Re: Google is killing the open web, part 2

#362

Post by shadowgovt »

righthand wrote: post #358
shadowgovt wrote: post #302

Earlier quoted context omitted.

What would that mean? XML is just text on the wire. If a browser stops supporting it... It's text on the wire. I slurp it in with JavaScript and parse it how I want. ... Actually, that seems like a fine idea...

Great lets remove the Html and Css renders too then. I can just slurp it in with Javascript and parse it how you want. No standards, do what you want!

The language in the browser for specifying what should show up and in what format is HTML and CSS. We can't remove them because we don't have anything to substitute; without them, there's just no displayable content.

Is your proposal that we replace those relatively heavyweight standards with something more primitive that we could then build the behavior on top of? I think there's meat on those bones. Quite frankly, the amount of work we do to push intent to fit the constraints of HTML and CSS in web apps is a little absurd relative to the frameworks and languages we have to do that in non-web widget toolkits. I'm not actually convinced that "Tk as an abstraction in the browser that we build HTML and CSS on top of" would be a bad thing (although we probably want to use something better than Tk, with more security guarantees).

... However, if we did that, we would really damage the accessibility story as it currently stands (since accessibility hinting is built on top of the HTML spec) and that's probably a bridge too far. We already have enough site developers who put zero thought into their accessibility; removing even the defaults HTML provides with its structure would be a bad call.

Post reply on HN