| 02:03 | <AryehGregor> | "The best demos that we’ve seen for D2D support are actually the IE Flying Images and the IE Flickr Explorer demo. Firefox actually performs wonderfully on these demos, better than the IE9 builds in most cases." Yay. |
| 02:03 | <AryehGregor> | And probably Firefox 4 will release before IE9. |
| 02:03 | <AryehGregor> | Now if only it has OpenGL support by then too. Otherwise the IE people will say "We're glad to say what great use other browsers can make of our awesome proprietary Windows(R) technology." |
| 02:03 | <MikeSmith> | heh |
| 02:06 | <MikeSmith> | I'm sure the Web graphics performance race will continue for quite a while |
| 02:06 | <MikeSmith> | with browser projects taking turns leapfrogging past each other |
| 02:06 | <MikeSmith> | hopefully |
| 02:07 | <AryehGregor> | Unfortunately, I darkly suspect that Linux will do poorly even once hardware acceleration is enabled, unless maybe you use a proprietary driver. |
| 02:07 | <AryehGregor> | I guess we'll see. |
| 02:10 | <MikeSmith> | fortunately, many desktop Linux users are accustomed to poor user experience and so have low expectations :) |
| 02:10 | <Slaanesh> | Implement OpenGL in canvas |
| 02:10 | <AryehGregor> | "The -moz-background-size property has been renamed to its final background-size name. -moz-background-size is no longer supported." Doesn't this encourage authors to specify foo alongside -moz-foo, thereby defeating the point of vendor prefixes? |
| 02:10 | <AryehGregor> | Slaanesh, you mean WebGL? |
| 02:10 | <Slaanesh> | No, OpenGL 1.5 |
| 02:10 | <AryehGregor> | A bunch of browsers have experimental implementations of that. |
| 02:10 | AryehGregor | looks up info about WebGL |
| 02:10 | <Slaanesh> | WebGL is basically OpenGL ES 2.0 |
| 02:11 | <AryehGregor> | . . . so what's the difference? |
| 02:45 | <MikeSmith> | we are still looking for an editor to pick up work on the WebIDL spec |
| 02:45 | <MikeSmith> | http://dev.w3.org/2006/webapi/WebIDL/ |
| 02:46 | <MikeSmith> | everlasting fame awaits the right person |
| 02:49 | <micheil> | Hixie: ping. (re that thread on hybi, just wanted to discuss something with you before repling) |
| 02:49 | <micheil> | *replying |
| 02:49 | <Hixie> | micheil: that is hardly the only spec awaiting an editor :-) |
| 02:49 | <Hixie> | micheil: hey |
| 02:49 | <micheil> | howdy' |
| 02:51 | <micheil> | Hixie: about the thing with the challenge being sent without a content-length, that was actually an issue when I was implemented the node.js server, this resulted in us changing the node.js http server to do a different thing if a request is an upgrade request, rather then a regular request |
| 02:51 | <Hixie> | indeed, that's the idea |
| 02:51 | <micheil> | and even now, without a content-length, I'm having to use a guess method to get the header, as if it isn't the right length sent, then I'm having to buffer to ensure it is. |
| 02:52 | <micheil> | and when I was implementing, I did check the http spec to find out that node was handling the request fine, according to http spec (which is what the node http parser was design to do), and that websockets weren't actually meeting spec |
| 02:53 | <Hixie> | web sockets is meeting the web sockets spec |
| 02:53 | <Hixie> | it's not http |
| 02:53 | <Hixie> | it just looks like http just enough to make it possible to share the port |
| 02:53 | <micheil> | but the initial handshake is over http protocol. |
| 02:53 | <Hixie> | no |
| 02:53 | <Hixie> | it's web sockets |
| 02:53 | <micheil> | well, okay then |
| 02:53 | <micheil> | but it does mean that you can't use the same server side parser as you would for compliant http |
| 02:54 | <micheil> | which adds a barrier to implementation |
| 02:54 | <Hixie> | you can't anyway, that would be non-conformming to web sockets |
| 02:55 | <Hixie> | for example, web sockets requires that you ignore continuation lines |
| 02:55 | <micheil> | then how could you have a server that does websockets respond to normal GET requests for pages? |
| 02:55 | <micheil> | if you don't use http spec in the handshake |
| 02:56 | <Hixie> | the only "correct" way to implement it if you really need to share a port with an http server is for the server to decide when it looks at the incoming data whether it thinks it's http or not (e.g. by looking for Upgrade: WebSockets) and if it thinks it is Web Sockets, to hand off the whole buffer and socket to another piece of code |
| 02:56 | <Hixie> | the whole "share the port with http" thing was a mistake though, imho |
| 02:56 | <micheil> | yeah, which is something that is almost impossible to do within node, without major code changes to the http server |
| 02:56 | <micheil> | I'd agree on it being a mistake, but I can see where it'd be useful. |
| 02:57 | <Hixie> | well, personally i would recommend not bothering supporting both protocols on one connection |
| 02:57 | <Hixie> | on one port i mean |
| 02:57 | <Hixie> | (you can never do it on one connection currently) |
| 02:57 | <micheil> | and now it's there, it sort of forces websockets to use the http parser, until the http parser know's that the data it's receiving is actually an upgraded http request |
| 02:57 | <Hixie> | it doesn't force it unless you decide to share the port |
| 02:57 | <Hixie> | which nobody is forcing anyone to do |
| 02:58 | <micheil> | although, because it looks like http, that's where people will start serving http off the same server |
| 02:59 | <micheil> | it then makes no sense for the websocket protocol to even initialize a connection with a http type header |
| 02:59 | <Hixie> | (btw, you can also just hack it by parsing the handshake per http, then handing the socket to the websockets code before sending back the 101) |
| 03:00 | <micheil> | that's what I do. |
| 03:00 | <Hixie> | i agree that it makes no sense for the websocket protocol to initialize a connection with a http type header, but it's probably to olate now |
| 03:00 | <Hixie> | given the implementations |
| 03:00 | <micheil> | node's http parser is evented, so, I get an "upgrade" event from it, instead of a "request" event, when it parsers the headers. |
| 03:00 | <Hixie> | makes sense |
| 03:01 | <Hixie> | the mail to hybi was about a reverse proxy, btw, not an http server |
| 03:01 | <Hixie> | which is a different kettle of fish and is even less valid imho as a complaint |
| 03:01 | <micheil> | however, because no content-length on the request body is set, we just have to rely on whatever the rest of the buffer after the headers is as the upgrade header |
| 03:01 | <Hixie> | (if you have reverse proxies, you really have no reason to be sharing the port, you surely have enough IP addresses to have a dedicated server) |
| 03:01 | <Hixie> | micheil: why? |
| 03:02 | <Hixie> | micheil: why can't you handle it the same way as the frames afterwards? |
| 03:02 | <micheil> | as far as I can see, if the websocket protocol is going to us a http handshake, and allow you to serve http off a websocket server, then the initial handshake should comply to http spec. |
| 03:02 | <micheil> | because, it's sent as one frame.. |
| 03:03 | <Hixie> | "sent as one frame"? |
| 03:03 | <Hixie> | what in the http spec does the web socket handshake violate? |
| 03:04 | <micheil> | in the sense that my server has always received the data in buffer, in that first data packet it receives from a connection as GET .... \r\n....\r\n\r\nChallenge\r\n |
| 03:04 | <micheil> | (maybe not the last \r\n) |
| 03:04 | <micheil> | well, from what I'm reading, websockets doesn't send a content-length when it sends a body, which is in violation of http spec. |
| 03:05 | <Hixie> | can you cite the actual statement that the handshake is violating? |
| 03:05 | <micheil> | more then likely not. |
| 03:05 | <Hixie> | i don't understand what you mean about the packets. There's nothing that guarantees the handshake will be in one TCP/IP packet. |
| 03:06 | <Hixie> | or that the frames won't be broken across packets. |
| 03:06 | <Hixie> | or that the end of the handshake and the start of the first frame won't be in the same packet, if the client didn't check the handshake (which it might not if it's a dedicated command-line client) |
| 03:06 | <micheil> | yeah, which is why I'm letting node's http parser handle the parsing of the incoming stream of data until it know's it's an upgrade |
| 03:07 | <Hixie> | i don't understand why you can't treat the first 8 bytes as just a spec kind of frame, like the rest of the frames |
| 03:07 | <micheil> | because it's often caught by the http parser |
| 03:08 | <micheil> | and as it's not stated as a body in the headers, the http parser that complies to spec doesn't know what to do with this extra data |
| 03:10 | <Hixie> | what would you do if we put the 8 bytes in the header somehow, and then the client sent a frame along with the handshake so that it appeared in the same packet? |
| 03:10 | <micheil> | it's the same issue as what was being seen by the reverse proxy |
| 03:11 | <micheil> | if the 8 bytes were as a header, I'd have no problems with that. |
| 03:11 | <micheil> | but there's still that backwards compat issue. now that chrome 6 supports draft76, it's going to be a major issue (as chrome auto-updates itself) |
| 03:12 | <Hixie> | i don't understand why the 8 bytes are an issue but the terabytes of potential data after the 8 bytes are not |
| 03:12 | <micheil> | if you have a "draft77" of the spec, which moves that 8 bytes into a header, then you're going to have then 3 protocols to try and support by the server |
| 03:13 | <micheil> | because, the way we're doing it is by hijacking the connection after we've parsed the GET request |
| 03:14 | <micheil> | this is all that I actually do outside of the http server in order to determine a websocket request: http://github.com/miksago/node-websocket-server/blob/master/lib/ws.js#L55-66 |
| 03:14 | <Hixie> | if the first packet from the client is "GET /foo bla bla bla handshake bla bla \r\n\r\n12345678[frame][frame][frame]", why is byte "8" going to be a disastrous problem, but the 0x00 byte immediately after it in the first [frame] in the _same TCP/IP packet_ not going to be a problem? |
| 03:15 | <micheil> | because, I've not yet seen any client that sends something like: GET /foo bla bla bla handshake bla bla \r\n\r\n123456780x00 |
| 03:15 | <Hixie> | there's no reason one couldn't exist |
| 03:15 | <micheil> | basically long of the short of what I'm saying is that I agree in adding the content-length |
| 03:16 | <micheil> | true, and the content-length would then ensure that the http parser know's to pause reading the buffer after it has received the defined number of bytes |
| 03:16 | <Hixie> | so the problem would also be solved by content-length: 0 ? |
| 03:17 | <micheil> | yes |
| 03:17 | <micheil> | but as the challenge body is part of the initial http request, it'd make more sense to do content-length: 8 |
| 03:17 | <micheil> | which would fix it for the reverse proxies as well |
| 03:18 | <Hixie> | then your server is buggy, because the http spec, as i understand it, says that GET implies content-length:0 if it's missing |
| 03:19 | <Hixie> | (content-length:8 would defeat the whole point, which is to make man-in-the-middle proxies fail to send the bytes because they look like the next request) |
| 03:20 | <micheil> | I don't actually know the internals of the http parser we're using. |
| 03:21 | <micheil> | and I would get the developer of it to explain it more clearly then I could, but he's not around at the moment |
| 03:23 | <Hixie> | (i can't actually find where in the http 1.1 spec it says how to determine the length of a GET request without an explicit content-length, but i'm pretty sure it has to assume it's zero, since otherwise you'd never know when the request was finished) |
| 03:23 | <micheil> | on the EOF? |
| 03:23 | <micheil> | or when you choose to close the request? |
| 03:24 | <Hixie> | if you just closed the request you wouldn't be able to get a reply :-) |
| 03:24 | <Hixie> | let alone pipeline multiple requests |
| 03:24 | <Hixie> | anyway, i'd be fine with adding a content-length:0 header, i just think it's pointless |
| 03:25 | <Hixie> | i'd be strongly against adding a content-length:8 header, for multiple reasons: |
| 03:25 | <Hixie> | 1. it would break the whole point of the 8 bytes |
| 03:25 | <Hixie> | 2. it would just bury the problem you described, so people would be less likely to test for it, even though the bug would still be there (e.g. with dedicated clients sending frames along with the handshake) |
| 03:27 | <micheil> | well, I mean, the way I've designed my websocket server to work, is to work either way, so I'm fine if the spec goes to either way |
| 03:28 | <Hixie> | yeah, 3. i'm not convinced it's actually a problem anyway |
| 03:28 | <Hixie> | it's probably a little more work for people reusing http servers, but my answer would be to not do that |
| 03:28 | <Hixie> | just write dedicated websocket servers, it's trivial to do |
| 03:29 | <micheil> | yeah, but parsing the headers of http, like the protocol says you should be doing, is often extremely difficult, and hence the reason people would be inclined to use a http server. |
| 03:31 | <micheil> | by extension, because the websocket protocol is sending an upgrade header, and not being a totally different protocol, it is in effect extending the HTTP protocol, so it is valid for it to be handled by a http server, until that server knows otherwise in which case it can handle it correctly |
| 03:32 | <micheil> | for instance, you could fire a websocket request at a non-websocket enabled server, and you'd just get back either a bad request response or a connection: closed |
| 03:33 | <micheil> | example: https://gist.github.com/7e4459073a89b4ed4ea9 |
| 03:33 | <micheil> | localhost:80 is just a standard nginx install |
| 03:34 | <micheil> | example with a valid url: https://gist.github.com/f25dc66f20f0d372a649 |
| 03:35 | <Hixie> | micheil: parsing the headers is _not_ hard, it's really easy. it's only hard if you have to share a port with an http server. |
| 03:35 | <Hixie> | micheil: don't forget web sockets has far simpler field parsing rules than http's header parsing rules |
| 03:35 | <micheil> | which is how the protocol is designed, and it's the most common thing I have requested for my server to do. |
| 03:36 | <Hixie> | what's the most common thing you have requested? |
| 03:36 | <Hixie> | i don't follow |
| 03:41 | <micheil> | the most common thing I have requested that my websocket-server support is to being able to handle standard http requests |
| 03:41 | <micheil> | as people want their websocket server to share the port with their http server |
| 03:42 | <Hixie> | do they say why? |
| 03:42 | <micheil> | because that's what their been told websockets does, and that's how they understand the protocol. |
| 03:43 | <micheil> | because it looks like http, people want to treat it as http, and I'm not going to disallow that, because I think it's the right method of going about it. |
| 03:45 | <Hixie> | so the reason people want the feature is that it's possible? |
| 03:45 | <Hixie> | that's pretty silly |
| 03:47 | <micheil> | and it's also how the spec reads. It currently reads in a way that says: "Websocket servers, may optionally also act as HTTP servers" |
| 03:48 | <micheil> | to quote: "The opening handshake is intended to be compatible with HTTP-based server-side software, so that a single port can be used by both HTTP clients talking to that server and WebSocket clients talking to that server" |
| 03:48 | <micheil> | section 1.3 of the protocol document. |
| 03:50 | <micheil> | the way that most people probably read that is that a websocket server should be able to handle http. it may be the wrong way of thinking about it, but it'd take a lot of effort to re-educate that that isn't how the protocol works |
| 03:50 | <micheil> | as it is, I have a hard enough time trying to explain to people that there's more to websockets now then what there was in draft75. |
| 03:51 | <micheil> | also, by not having a websocket-server act as a http server, you remove the possibility of allow degrades like Sockets.io uses, where by it'll try and use websockets, if that fails, then it'll use comted |
| 03:51 | <micheil> | *cometd protocol / bayeux |
| 03:54 | <Hixie> | i think it's fine that we make it possible, because there are use cases where it does make sense |
| 03:54 | <Hixie> | i'm a little concerned that people are thinking this is the main way to use the protocol |
| 03:54 | <Hixie> | because that rather misses the point, which is that writing a custom websocket server is a weekend's work at most |
| 03:56 | <micheil> | it's taken me more then a weekend to implement my websocket server, for sure. |
| 03:56 | <Hixie> | sure, but you're also doing it with http |
| 03:56 | <micheil> | the only case where it's a weekend's work, is if you're highly familiar with IETF specs. |
| 03:57 | <Hixie> | if you just do a straight websocket server, with no http at all, it's trivial |
| 03:57 | <Hixie> | you just follow the spec |
| 03:57 | <Hixie> | it's like 150 lines of perl |
| 03:57 | <micheil> | actually, I was able to implement it much easier using the http as a basis. |
| 03:57 | <micheil> | because of the different clients I tested, each sent the headers in a slightly different way |
| 03:58 | <Hixie> | well, right now it's more difficult than it should be because of the various versions, for sure |
| 03:58 | <Hixie> | i just mean once the spec is interoperably implemented |
| 03:59 | <micheil> | you'll always have older clients. |
| 04:00 | <micheil> | are you going to refuse an IE visitor access to your site because they don't support border-radius? I doubt it. |
| 04:00 | <Hixie> | i'm just talking about websockets |
| 04:01 | <micheil> | yeah, and in which case, are you going to refuse people using chrome 5 or safari 5 access to your site because they don't support draft76? |
| 04:01 | <micheil> | it'd be the same issue as what we get with the CSS spec. |
| 04:01 | <Hixie> | both chrome and safari update very very quickly, such that that won't be an issue for long |
| 04:02 | <micheil> | umm.. safari hasn't yet updated to draft76, and safari 5 was released when 76 was available, so, go figure. |
| 04:05 | <Hixie> | sure, but the spec isn't done yet |
| 04:05 | <Hixie> | there might well be further breaking changes |
| 04:05 | <Hixie> | my point is that once we're stable, someone implementing a server that just works with compliant clients will be very easy. |
| 04:10 | <micheil> | yeah, but we know they clients are generally never compliant |
| 04:11 | <micheil> | because even when the spec is stable, you may still have Joe connecting using chrome 5, or safari 5, because their organisation hasn't / can't upgrade to a newer version of the browser |
| 04:11 | <micheil> | which while that scenario is unlikely, it's something to plan for, because it will happen. |
| 04:12 | <Hixie> | i'm more optimistic :-) |
| 04:12 | <micheil> | I've already seen it, and consequentially I've implemented an auto mode in the server to automatically choose which handshake to use be it draft76 or draft75 |
| 04:12 | <Hixie> | yes, but again, right now is not a normal situation |
| 04:13 | <micheil> | and if you tell the server to only support version X, then clients connecting using version Y will be rejected |
| 04:13 | <micheil> | but the thing you have is that people want to support the most client's possible. |
| 04:13 | <micheil> | there's no point in using websockets now, if you can only use them in chromium 6. |
| 04:13 | <micheil> | (and possibly chrome 6 by extension) |
| 04:14 | <Hixie> | yes i understand; in due course, however, all the deployed clients will be compliant |
| 04:14 | <Hixie> | so it'll be a non-issue |
| 04:14 | <micheil> | how many years? 1? 2? 5? 10? 20? |
| 04:14 | <micheil> | it'll be the same issue as what has been seen in the css spec and implementation |
| 04:15 | <Hixie> | i predicted it would be so by 2022 |
| 04:15 | <Hixie> | for the stuff that was in web apps 1.0 in 2006, which includes what is now known as web sockets |
| 04:16 | <Hixie> | so <12 years? |
| 04:16 | <micheil> | right.. so.. basically you're saying that no one should use websockets yet at the moment, when the demand for them is now. |
| 04:17 | <Hixie> | demand ain't gonna go down :-) |
| 04:18 | <micheil> | are we even going to be using http in 12 years time? |
| 04:18 | <micheil> | are we going to be using a web browser as it is today in 12 years time? |
| 04:18 | <Hixie> | we were 20 years ago, so, sure |
| 04:18 | <Hixie> | what else would we use? |
| 04:18 | <micheil> | to put in perspective, I didn't know the web really existed 12 years ago. |
| 04:19 | <micheil> | I would've actually only been 5 years old. 12 years is a bloody long time. |
| 04:19 | <Hixie> | sure |
| 04:19 | <Hixie> | but it takes a bloody long time for things to change, too |
| 04:22 | <Hixie> | i don't see why a technology that hasn't been invented yet would be able to take over and be more widely implemented and usable than a technology that already exists |
| 04:23 | <micheil> | well, as far as I've seen it's been almost instant with the adoption of changes to the websocket protocl. |
| 04:23 | <micheil> | chrome 5 -> chrome 6. |
| 04:23 | <micheil> | that's maybe 1 year at most. |
| 04:24 | <micheil> | which is very quick adoption. |
| 04:24 | <micheil> | but then, only 2 months before chrome 6 was released, we had safari 5 released that was supporting the older spec, not the newest spec. |
| 04:25 | <micheil> | as for firefox, opera, and IE, I have no idea where they currently stand on implementing websockets. |
| 04:25 | <micheil> | (and I haven't had time to test each version.) |
| 04:25 | <Hixie> | i hope that it'll be a lot less than 12 years in practice |
| 04:25 | <Hixie> | 2022 was just the date for everything in the spec; it's quite possible some things will be ready sooner |
| 04:26 | <micheil> | but my point still stands that you'll have some people become dependent on draft75, hence can't upgrade to draft76, hence locking them out of using websites that use draft76 |
| 04:34 | <Hixie> | micheil: i am seriously completely unconcerned by people getting "dependent" on a draft that is only currently implemented by one browser |
| 04:34 | <Hixie> | especially since it was a highly unstable draft |
| 04:35 | <Hixie> | and anyone implementing it is basically asking for trouble |
| 04:35 | <Hixie> | since it has known security flaws |
| 04:35 | <micheil> | I know people who already have. and by you being unconcerned by it, it totally breaks everything that's been said about progressive enhancement being good practice |
| 04:35 | <micheil> | like I said, the demand for websockets is now. not sometime in the next 12 years. |
| 04:36 | <Hixie> | i hate to be blunt, but there's a difference between being backwards compatible with established technologies, and being backwards compatible with insecure unstable working drafts |
| 04:36 | <Hixie> | we can't be held hostage to people playing with experiments |
| 04:36 | <micheil> | okay then. |
| 04:36 | <Hixie> | the demaind for websockets isn't going away any time soon |
| 04:36 | <Hixie> | demand, even |
| 04:36 | <micheil> | yeah, but the fact is, it's now. people want to use it now. |
| 04:37 | <Hixie> | sure |
| 04:37 | <Hixie> | and tomorrow |
| 04:37 | <Hixie> | and the day after |
| 04:37 | <Hixie> | and also yesterday |
| 04:37 | <Hixie> | and the day before that |
| 04:37 | <Hixie> | that's why we are working on it |
| 04:37 | <Hixie> | not much point working on technologies that don't have demand :-) |
| 04:37 | <micheil> | I've already had clients come to me wanting to use websockets, because their interfaces demand for it. Should I just tell them: "Sorry, but websockets aren't ready for public comsuption yet"? |
| 04:38 | <Hixie> | yes |
| 04:38 | <micheil> | I'm not going to do that, because I'm a freelancer. I need the money. I'm not going to deny myself the option to earn it. |
| 04:38 | <micheil> | If I don't do it, then there'll be someone else that does. |
| 04:39 | <micheil> | I can recommend that websockets are an unstable protocol, but I'm not going to decline to work on it. |
| 04:40 | <Hixie> | that's fine, as long as they (and you) understand that you might get screwed again if we change the protocol :-) |
| 04:40 | <micheil> | to give context, the big demand for rounded corners was in the "web 2.0 era", it's not so much now. now it's just a nice design decision, and we've learnt that some browsers just won't get the rounded corners (progressive enhancement) |
| 04:41 | <Hixie> | well i'm glad to say that i think web sockets will be ready before rounded corners, but that says more about the csswg than anything else |
| 07:04 | <jwm> | now we just need websocket server support in browsers |
| 07:04 | <jwm> | *cough* |
| 07:04 | <jwm> | hehe |
| 09:13 | <annevk> | Hixie, should just pick a non-HTTP port again and push back on IANA maybe |
| 09:43 | <zcorpan_> | so does adding connection: close solve the reverse proxy problem? |
| 10:39 | <MikeSmith> | fwiw, I just made a change to the "Edition for Web Authors" subset of the spec (static copy of the "Hide UA text") view |
| 10:40 | <MikeSmith> | the change is to some of the link behavior |
| 10:41 | <MikeSmith> | there are some links in the author view with fragment IDs that are not actually in the author view |
| 10:41 | <MikeSmith> | only in the full spec |
| 10:43 | <MikeSmith> | so what I did was to cause those to be rewritten (in the generated static copy) so that they are absolute URLs to the full spec |
| 10:43 | <MikeSmith> | instead of (broken) fragment references |
| 10:43 | <MikeSmith> | and I added some :hover styling for them |
| 10:44 | <MikeSmith> | see for example, http://dev.w3.org/html5/spec-author-view/timers.html#timers |
| 10:44 | <MikeSmith> | hover over the "setTimeout()" link |
| 10:45 | <MikeSmith> | if anybody has suggestions for how to better style those, lemme now |
| 10:46 | <MikeSmith> | the way I have it now, there's no visual indicator that it's an external link to the full spec |
| 10:46 | <MikeSmith> | you don't know until you hover over it whether it is or not |
| 10:47 | <MikeSmith> | but maybe there should be some visual indication that shows up even if you don't hover |
| 10:47 | <MikeSmith> | I just didn't want to add anything additional that would be obtrusive/annoying |
| 10:48 | <MikeSmith> | e.g., it's going to show up in pretty much all the IDLs |
| 10:48 | <zcorpan_> | MikeSmith: changing the layout on hover is annoying. could you use outline instead of border or something? |
| 10:48 | <MikeSmith> | because the links in the IDLs are mostly definitions in the full spec |
| 10:48 | <MikeSmith> | zcorpan_: sure |
| 10:48 | <MikeSmith> | if I know the CSS |
| 10:49 | <MikeSmith> | um, is outline a CSS property? |
| 10:49 | <zcorpan_> | yeah |
| 10:49 | <zcorpan_> | and no horizontal padding |
| 10:49 | <MikeSmith> | hai |
| 10:49 | <MikeSmith> | will make an attempt right now |
| 10:50 | zcorpan_ | would be ok with no vertical padding too |
| 10:50 | <MikeSmith> | zcorpan_: yeah, agreed it's annoying |
| 10:52 | <zcorpan_> | MikeSmith: the "This box is non-normative. Implementation requirements are given below this box." text is not really accurate |
| 10:52 | <MikeSmith> | hmm, yeah |
| 10:52 | <zcorpan_> | maybe just remove them |
| 10:52 | <MikeSmith> | I think that's something that Hixie will need to change in teh upstream source |
| 10:53 | <MikeSmith> | zcorpan_: they show up in the dynamic "Hide UA text" view also |
| 10:54 | <MikeSmith> | I guess the text "Implementation requirements are given below this box." should probably be marked up with span/@class=impl |
| 10:54 | <zcorpan_> | i thought it was css-generated |
| 10:54 | <MikeSmith> | oh |
| 10:55 | <MikeSmith> | if it is, then that's easy enough to tweak |
| 10:55 | MikeSmith | checks the stylesheet |
| 10:55 | <MikeSmith> | doesn't appear to be CSS-generated |
| 10:56 | <MikeSmith> | is there a way that I can have an outline that bleeds over the surrounding text? |
| 10:56 | <annevk> | are you sure it's not CSS-generated? |
| 10:56 | <annevk> | pretty sure it is |
| 10:56 | <annevk> | if this is about domintro boxes |
| 10:56 | <MikeSmith> | that is, with padding that doesn't cause surrounding text to be pushed aside or up or down |
| 10:58 | <MikeSmith> | maybe I'm not looking at the right stylesheet |
| 11:00 | <MikeSmith> | hmm, yeah, it's definitely generated |
| 11:08 | <MikeSmith> | "The outline created with the outline properties is drawn "over" a box, i.e., the outline is always on top, and does not influence the position or size of the box, or of any other boxes. Therefore, displaying or suppressing outlines does not cause reflow or overflow." |
| 11:08 | <MikeSmith> | http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines |
| 11:09 | <MikeSmith> | so again I wonder how I can specify an outline with a padding such that it doesn't cause any reflow |
| 11:11 | <MikeSmith> | oh, offset |
| 11:39 | <MikeSmith> | zcorpan_: updated with attempted improvements |
| 11:39 | <MikeSmith> | I removed the domintro:before generated text |
| 11:39 | <MikeSmith> | and changed the link styling to outline with and offset |
| 11:40 | <MikeSmith> | *an offset |
| 11:46 | <Lachy> | reading through the change proposal for doctype versioning (ISSUE-4), since the poll apparently starts next week, there are so many technical problems with it, even ignoring the fact that it's a bad idea |
| 11:49 | <MikeSmith> | zcorpan_: hang on for a minute.. seems my commit failed for some reason |
| 11:50 | <Lachy> | ... like the fact that it doesn't actually provide any justification for needing a completely useless versioning syntax, especailly when it says that UAs must not implement any other DOCTYPE specific behaviour |
| 11:54 | <MikeSmith> | http://techcrunch.com/2010/07/06/freelancer-geolocation-html5-jobs/ |
| 11:56 | <MikeSmith> | ". As a result of what the company dubs the ‘Apple effect’, Freelancer.com also saw a significant 721% boost in HTML5 jobs." |
| 11:59 | <Philip`> | That's a lot of significant figures |
| 11:59 | <MikeSmith> | dunno what constitutes an "HTML job" |
| 12:00 | <MikeSmith> | I suppose any job ad that mentions "HTML5" |
| 12:01 | <MikeSmith> | I wonder if they count jobs adds that say "we think HTML5 is hype and we're not looking for 'HTML5' developers so if you are an 'HTML5' developer please apply somewhere else for 'HTML5' work instead of here, where we're not looking got any kind of HTML5 stuff" |
| 12:02 | <MikeSmith> | zcorpan_: checked in and synced up now on http://dev.w3.org/html5/spec-author-view/ |
| 12:02 | <MikeSmith> | fwiw |
| 12:03 | MikeSmith | prepares to hook up the trailer to his riding lawn mower for the drive back home |
| 12:14 | <annevk> | MikeSmith, outline-offset |
| 12:14 | <annevk> | iirc |
| 12:17 | <karlcow> | for what is worth, more and more RFPs, we receive at the Web agency for the last 3 months contain sentences such as "We want the website compatible html5" or "requirements: html 5 ready (iphone and ipad)" |
| 12:17 | <karlcow> | people associate html5 with iphone and ipad. |
| 12:17 | <karlcow> | They often mean, "no flash on ipad and iphone". |
| 12:18 | <annevk> | RFP? |
| 12:18 | <karlcow> | Request For Proposal - usually the document the client sends to a few agencies for getting the best (underpriced) proposals |
| 12:21 | <MikeSmith> | karlcow: interesting.. seems in line with comment in that article about the "Apple effect" |
| 12:22 | <MikeSmith> | annevk: thanks, yeah, outline-offset is what I used |
| 12:23 | <MikeSmith> | file:///opt/workspace/html5/spec-author-view/style.css |
| 12:23 | <MikeSmith> | oops |
| 12:23 | <MikeSmith> | make that http://dev.w3.org/html5/spec-author-view/style.css |
| 12:51 | <zcorpan_> | seems like MikeSmith found a bug in opera |
| 13:17 | <karlcow> | http://news.bbc.co.uk/2/hi/technology/10525509.stm |
| 13:17 | <karlcow> | "The Taiwanese smartphone maker HTC has reported a 41% sales increase for the first six months of 2010." |
| 13:50 | <boblet> | hsivonen: did anything come of the lint checker option idea adactio and others were desiring for the validator? |
| 13:51 | <adactio> | There's this: http://lint.brihten.com/html/ |
| 13:51 | <annevk> | nobody came with a sensible list of requirements iirc |
| 13:51 | <annevk> | Sam Ruby tried to gather some, but it never really want anywhere |
| 13:51 | <annevk> | went, even |
| 13:51 | <adactio> | That URL has a sensible list of requirements. |
| 13:52 | <annevk> | it has a few radio buttons :) |
| 13:53 | <adactio> | Those are the things that authors want. |
| 13:53 | <annevk> | but sure, you can derive something from that, but is that what everyone wants? |
| 13:53 | <adactio> | It's what 99% of authors want. |
| 13:53 | <annevk> | for instance the TAG and these polyglot people want XML-compatibility, that's not really important? |
| 13:53 | <adactio> | Nope, not for a lint tool. Completely different use case. |
| 13:53 | <adactio> | A lint tool is purely about writing style. |
| 13:54 | <adactio> | It has nothing to do with parsing. |
| 13:54 | <annevk> | sure it does, you can enforce a writing style that ensures that parsing later does not result in surprises |
| 13:54 | <adactio> | That's what I kept trying to get across (to Henri, to Sam, etc.) but the talk would always keep coming back to polyglot documents ...which is something completely different. |
| 13:55 | <adactio> | you *can* enforce a writing style for polyglot documents but that's not why 99% of authors have a writing style. |
| 13:55 | <annevk> | agreed |
| 13:56 | <annevk> | I wonder if we created a wiki page for this |
| 13:56 | <adactio> | You're focusing on the 1% use case: attempting to derive a "safe" writing style for polyglot documents when 99% of the time, all people want is as simple as "tell me if I forget to quote an attribute." |
| 13:57 | <annevk> | I'm not, I'm just the messenger |
| 13:58 | <annevk> | I'm trying to explain where it stopped last time |
| 14:00 | <annevk> | http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed |
| 14:00 | <annevk> | I guess "Polyglot" should just be dropped and "Pedagogical" be turned into a bunch of lint checking options |
| 14:01 | <annevk> | I'd like a validator that tell me whether I'm using tabs rather than spaces :) |
| 14:01 | <adactio> | Right. I think the term "polyglot" is guaranteed to derail any discussion of lint tools. "Pedagogical" works for me. |
| 14:07 | Philip` | thinks "lint" is much easier to spell and pronounce than "pedagogical", and doesn't look like it could be a rude word |
| 14:07 | <annevk> | http://wiki.whatwg.org/wiki/HTML_Lint_Checking |
| 14:57 | <hsivonen> | boblet: no, and I'm not sure who dropped the ball |
| 14:59 | <boblet> | hsivonen: I’m imagining the ppl who would like that function are hoping the legions of crack programmers maintaining validator.nu are on it ;-) |
| 14:59 | <boblet> | …blame MikeSmith ? |
| 15:00 | <MikeSmith> | boblet: what function? |
| 15:00 | <hsivonen> | boblet: I thinkI said I wouldn't do it right away but Sam's patches would be welcome |
| 15:00 | <boblet> | [9:56pm] boblet: hsivonen: did anything come of the lint checker option idea adactio and others were desiring for the validator? |
| 15:01 | <boblet> | adactio: woah completely missed your reply, orz |
| 15:01 | <hsivonen> | boblet: and Sam made it clear that he'd only work on it if zeldman and tantek were precise about what they wanted |
| 15:02 | <boblet> | hsivonen: so “just like validator.nu, but more anal” isn’t accurate enough? hrm |
| 15:03 | <adactio> | hsivonen: I don't think it necessarily needs to be incorporated into the validator. I'm quite happy having my lint tool at http://lint.brihten.com/html/ as long as it also pipes documents through the validator. |
| 15:03 | <hsivonen> | I'm at the same conference as tantek, so maybe I can ask him wha happened if I find him |
| 15:03 | <boblet> | I could have a crack but I’m sure I wouldn’t do as precise a job as t would |
| 15:03 | <boblet> | hsivonen: please do. I might email him too (something else I wanted to ask about and he hasn’t been in IRC much recently) |
| 15:04 | <adactio> | I propose a version of Godwin's law whereby, in a discussion of what should be in a lint tool, any mention of "polyglot" invalidates the discussion. |
| 15:06 | <boblet> | adactio: if validator.nu offered that feature it’d be a good thing tho, esp. if it then gets rolled into validator.w3.org |
| 15:06 | <Philip`> | hsivonen: Would you be reluctant to add link-checking features that were incompatible with high-performance parsing (e.g. having the tokenizer store extra data about tokens), and that would either cause performance regressions or add significant complexity or require code forks? |
| 15:07 | Philip` | is wondering whether validator.nu could do everything by itself, or if it needs a completely separate lint-checking layer |
| 15:07 | <Philip`> | s/link-checking/lint-checking/ |
| 15:07 | <boblet> | adactio: actually would you have the time to whip up a precise list of stuff you’d like? |
| 15:07 | <adactio> | boblet: I agree. But every effort to get a discussion about lint tools into validator.nu inevitably gets hijacked by polyglot fans. So, at this stage, I think things will move faster somewhere else. |
| 15:07 | <adactio> | bobet: The radio buttons here are my list: http://lint.brihten.com/html/ |
| 15:08 | <adactio> | boblet: in fact, I'd leave off the "misc" category myself. The other 6 things are it, really. |
| 15:08 | <annevk> | I put them here: http://wiki.whatwg.org/wiki/HTML_Lint_Checking |
| 15:08 | <annevk> | so other people can add/subtract |
| 15:09 | <adactio> | annevk: Thanks. |
| 15:09 | <adactio> | It might be good to have a *separate* place to discuss the creation of polyglot conformance checker (to make it clear that they are separate use cases). |
| 15:09 | <Philip`> | adactio: That hijacking seems inevitable if you ask people to justify their demands, since the justification given for most syntax requirements is "I want to be able to parse pages as XML", so I guess we need to stop asking people why they want to check the things they say they want to check |
| 15:10 | <boblet> | just read the earlier conversation (polyglot vs pedagogical/lint) and now know what everyone’s talking about (was in skype mtng) |
| 15:10 | <adactio> | Philip: I don't think there needs to be any justification required for a lint tool. Isn't the whole point of, for example, a coding style in a programming language, that it's basically personal preference? |
| 15:11 | <adactio> | Philip: so yes, I agree: no need to ask "why?" |
| 15:12 | <boblet> | Philip`: also it’s intended more for the silent majority |
| 15:14 | <Philip`> | adactio: Yeah, I don't think we do need to have justification - it won't be a coherent set of rules derived logically from a precise high-level goal, but it'll satisfy people and it'll lead them towards less ugly markup |
| 15:14 | <adactio> | Yup. |
| 15:15 | <boblet> | hsivonen: so if we have a list of desired features, would it be possible to get them incorporated into validator.nu? or still the same low priority status issue? |
| 15:15 | <hsivonen> | Philip`: I'm planning on adding an API for listening to tokenizer state transitions for source highlighting use. Time will tell if it becomes useful for linting, too. |
| 15:15 | <Philip`> | Perhaps the best way to justify the set of rules is to implement everything that's suggested, measure how many people use them, then remove the ones that aren't worth the code/UI complexity they add |
| 15:16 | <hsivonen> | Philip`: I have plans to strip the code out for other use cases |
| 15:16 | <hsivonen> | the readability of the tokenizer source is going to suffer a bit |
| 15:18 | <hsivonen> | I consider it a step forward that the lint discussion is being detached from the polyglot discussion |
| 15:19 | <hsivonen> | but I don't know if all the people who want a 'lint' want at all the same thing |
| 15:21 | <boblet> | hsivonen: if asking what ppl want invokes the specter of polygot and lint.brihten.com is a working example of what ppl want, implementing those 6 things as adactio suggests then asking questions second would be great |
| 15:24 | <Philip`> | hsivonen: Would the API be sufficient for e.g. allowing <input ... disabled> but not allowing <img ... alt> (and probably not <embed ... disabled>) (i.e. context-dependent valueless attributes)? |
| 15:26 | <Philip`> | (I would guess the normal relatively-clean tokenizer/tree constructor separation might make it hard when you want to do checks that cross both layers) |
| 15:28 | <Philip`> | (...but I don't know enough about the implementations to do more than guess) |
| 15:28 | <boblet> | nn |
| 15:53 | <adactio> | So here's something that been bothering me: should a user agent prevent a form being submitted if one field is suffering a type mismatch *even if that field is not required*? |
| 15:53 | <adactio> | Test cases here: |
| 15:53 | <adactio> | http://andyhume.net/testing/forms.html |
| 15:54 | <annevk> | yes |
| 15:54 | <adactio> | In the 2nd and 3rd examples, the form can be submitted if the url or email field is empty but not if the url or email field has an invalid value. |
| 15:54 | <adactio> | That's awful! |
| 15:54 | <annevk> | that's the whole point of form validation |
| 15:55 | <adactio> | No, the whole point of form validation is to allow you (the author) to decide what to do in the case of type mismatch. |
| 15:56 | <adactio> | For the user-agent to automatically cancel the submission of a form when a non-required field suffers from a type mismatch is the browser equivalent of the "nanny state". |
| 15:56 | <annevk> | in the simple case you want submission to be prevented because otherwise the server will have to complain and it costs the user (and you) a roundtrip |
| 15:57 | <annevk> | there may be more complex cases, but those are not (yet) addressed |
| 15:57 | <adactio> | The server will have to complain if it's a required field. Otherwise, no. |
| 15:57 | <annevk> | though you can do something via scripting for sure |
| 15:57 | <annevk> | adactio, there's more use cases than the one you are interested in :) |
| 15:57 | <annevk> | there're grmbl |
| 15:58 | <hober> | If a field is optional, but has validation constraints, then those validation constraints should be enforced if the element has a non-"" value |
| 15:58 | <adactio> | annevk: the use cases I'm talking about came from other people ...who are now changing everything back to input type="text" to avoid webkit's over-zealous behaviour with type mismatches. |
| 15:59 | <hober> | essentially, putting validation constraints on an optional field means "we accept empty xor *like this*" |
| 15:59 | <annevk> | adactio, well yes, WebKit has a stupid non-UI implementation |
| 15:59 | <annevk> | adactio, that's not the fault of the specification, but of WebKit for shipping something broken |
| 16:00 | <adactio> | It's not about the UI. |
| 16:01 | <annevk> | in Opera it is clear why the form is not submitted |
| 16:01 | <Philip`> | Why would you put validation constraints on a non-required field if you don't want the value to be validated against those constraints? |
| 16:01 | <adactio> | I find Opera's behaviour equally wrong *as long as the field is not required*. |
| 16:01 | <adactio> | semantics |
| 16:01 | <annevk> | I don't see how required is more important than valid |
| 16:02 | <annevk> | should it be submitted if it's required and invalid? |
| 16:02 | <annevk> | i guess not per your reasoning, but that would make even less sense then |
| 16:02 | <hober> | required means "this element must have a non-'' value" |
| 16:02 | <hober> | which is orthogonal to value constraints |
| 18:07 | <karlushi> | I wonder if anyone has evaluated when Chrome will start flirting with firefox http://en.wikipedia.org/wiki/File:Usage_share_of_alternative_web_browsers.svg |
| 18:08 | <karlushi> | 2012? |
| 18:16 | <TabAtkins> | adactio: Webkit's behavior (assuming they hook up actual UI to it, dammit) is precisely what I would expect, for precisely the reason hober outlined - if I say something is non-required but has a pattern, I expect it to mean "empty, or matching this pattern". |
| 18:17 | <TabAtkins> | adactio: If I'm reading what you want right, it would make the various pattern attributes entirely useless on a non-required field. |
| 18:17 | <TabAtkins> | AryehGregor: I' |
| 18:17 | <TabAtkins> | AryehGregor: I'm not the most useful twitterer. I'm curious as to what in specific that I post if making you glad you're avoiding twitter, though? |
| 18:19 | TabAtkins | forgot that his tweets turn into buzzes anyway - he only uses the google-internal buzz. |
| 18:36 | <JonathanNeal> | Is it acceptable to make a label on an input be hidden accessible? |
| 18:42 | <TabAtkins> | JonathanNeal: I don't understand the question - the last part of the sentence doesn't parse. |
| 18:44 | <JonathanNeal> | Sure, let me see if I can describe it. |
| 18:45 | <JonathanNeal> | <span class="field-content"><label class="hidden-accessible" for="someInput">Some Input</label><input id="someInput" type="text" /></span> |
| 18:45 | <JonathanNeal> | Where .hidden-accessible is visually implied, but there is a textual fallback. |
| 18:45 | <JonathanNeal> | it's hidden, but there's a text label for screen readers. |
| 18:46 | <TabAtkins> | Oh, okay. |
| 18:46 | <TabAtkins> | Then, yes? That's just standard accessibility stuff. |
| 18:46 | <JonathanNeal> | Okay, I wasn't sure if there were different rules for <label>s. |
| 18:48 | <TabAtkins> | Only insofar as radio buttons by themselves are sorta hard to click or whatever, so having a label is good to make it more clickable. But if you're doing other stuff to make it clickable and the label isn't otherwise necessary, then sure, yeah, hide it visually but make it accessible. |
| 18:50 | <JonathanNeal> | Would you know if "aria-hidden" should be read by screen readers? |
| 18:51 | <TabAtkins> | No clue. It sounds like maybe not, though. If you want it accessible, then it shouldn't be denoted as "hidden". |
| 18:51 | <TabAtkins> | (Presumably hidden things shouldn't be looked at.) |
| 18:51 | <TabAtkins> | I don't think you have to do anything with aria at all here. Just do the standard abspos hack. |
| 18:53 | <JonathanNeal> | Fair enough, I wasn't sure if there was a hidden accessible type-of-role for it. |
| 18:53 | <JonathanNeal> | Thanks. |
| 19:04 | <JonathanNeal> | So what was confusing about my question, the phrase "hidden accesible"? |
| 19:05 | <TabAtkins> | Yeah - I wasn't able to parse that as a single word. |
| 19:05 | <TabAtkins> | s/word/phrase/ |
| 19:05 | <TabAtkins> | or whatever |
| 19:12 | <JonathanNeal> | Is there a better word / phrase I could have used? |
| 19:13 | <TabAtkins> | "Is it acceptable to make a label on an input be visually hidden but still accessible?" |
| 19:13 | <TabAtkins> | "hidden accessible" sounded to me like it was accessible to hidden things. ^_^ |
| 19:15 | <Hixie> | how can something be accessible if it's hidden? |
| 19:15 | <TabAtkins> | "hidden" = "absposed off the left screen edge" |
| 19:15 | <TabAtkins> | So visually hidden, but not hidden from screenreaders and such. |
| 19:16 | <Hixie> | well if it's off the screen edge, i ain't gonna be able to access it |
| 19:16 | <Hixie> | so it doesn't seem accessible |
| 19:16 | <TabAtkins> | ?_? |
| 19:16 | <Hixie> | something that's only accessible to screen readers isn't accessible |
| 19:16 | <Hixie> | it's just limited to screen reader users |
| 19:16 | <TabAtkins> | Yes, you won't be able to access it if you're using a normal browser. That's the point. |
| 19:16 | <TabAtkins> | It's like that on purpose. |
| 19:17 | <Hixie> | seems weird to call that "accessible" |
| 19:17 | <Hixie> | since it's the opposite of accessible |
| 19:17 | <Hixie> | it's like something that's only visible to screen users |
| 19:17 | <TabAtkins> | Eh, that's common usage. "accessible" means "still usable by someone using something other than a normal browser". |
| 19:17 | <TabAtkins> | In the common webdev-hack parlance. |
| 19:17 | <Hixie> | "accessible" means "usable by everyone" |
| 19:17 | <TabAtkins> | If it's usable by a normal browser you dont' have to use a word for it at all. ^_^ |
| 19:17 | <Workshiva> | We have always been at work with alt text |
| 19:18 | <Hixie> | alt text is an example of this... the alt text isn't accessible, nor is the png file, it's the <img> that becomes accessible when you provide both the image file and the alt text |
| 19:19 | <TabAtkins> | Correct. And? This is a different issue entirely. |
| 19:19 | <TabAtkins> | (Are you just arguing about the use of the term?) |
| 19:19 | <Hixie> | yes |
| 19:19 | <JonathanNeal> | The idea is that implicit visual functionality is lost to non visual users. |
| 19:19 | <TabAtkins> | Ah, then shrug. Like I said, that usage is common in webdev-hack parlance. |
| 19:20 | <JonathanNeal> | Like certain calendar input fields, or a "skip to main content" link. |
| 19:20 | <Hixie> | i think a big part of the problem with making context universally accessible is the view point that the visual presentation is somehow privileged |
| 19:20 | <JonathanNeal> | So, I was using the phrase "hidden accessible" to describe how it is hidden to the visual user who would not need the additional accessibility. |
| 19:21 | <Hixie> | referring to things that aren't visible as "accessible" is a symptom of that viewpoint imho |
| 19:21 | <TabAtkins> | If it's just a symptom, then changing it won't affect anything. ^_^ |
| 19:21 | <JonathanNeal> | Hixie, the visual presentation is privileged, communication happens in more ways than just text. |
| 19:22 | <Hixie> | "the audio presentation is privileged, communication happens in more ways than just text" is equally true |
| 19:22 | <TabAtkins> | But yeah, since most people (and especially most devs) have working vision and motor skills, there is indeed a privileged presentation in practice. |
| 19:22 | <JonathanNeal> | That's why alt exists, because the visual presentation is privileged to show you a picture of a kitten without necessarily having to textually describe it for you. |
| 19:23 | <JonathanNeal> | Hixie, yes, this is true, the audio presentation is privileged. |
| 19:24 | <Hixie> | my point is that the right way to think about this is to view the markup as media-independant, so that no medium is privileged. |
| 19:24 | <Hixie> | crap, i gotta go, meeting |
| 19:24 | Hixie | hastily climbs off his soapbox and packs it away |
| 19:24 | <Hixie> | later |
| 19:24 | <JonathanNeal> | Later. |
| 19:24 | <TabAtkins> | Hixie: So you're missing the point of the hack itself anyway, which is to make a media-independent markup and then visually hide the bits that the visual presentation doesn't need. |
| 19:24 | <JonathanNeal> | So, hidden accessible maybe isn't the best term. |
| 19:25 | <JonathanNeal> | non-presentational |
| 19:26 | <TabAtkins> | Just say "visually hidden, but still otherwise accessible", like I said. That captures the intent exactly, and Hixie's just overreacting. |
| 19:26 | <TabAtkins> | Or rather, he's reacting to something else that he mistakenly thinks you're saying. |
| 19:32 | <JonathanNeal> | okay, so when I say hidden accessible what I mean to say is "visually HIDDEN but still otherwise ACCESSIBLE" |
| 20:05 | <AryehGregor> | TabAtkins, I'm sure they're fine, as far as tweets go. But nearly all of them are just random unconnected thoughts that at *best* are only very mildly interesting to me. |
| 20:05 | <AryehGregor> | I think my remark was triggered by "OMIGOD FRESH BREAD OMNOMNOMNOMNOM". |
| 20:05 | <AryehGregor> | I guess maybe it's good if you want to know what the tweeter is thinking about, or somesuch. |
| 20:07 | <TabAtkins> | AryehGregor: That is, indeed, largely what tweeting is about. |
| 20:08 | <TabAtkins> | Also, that sort of thing would normally just go to my facebook, but I posted it from my phone, which by default pushes stuff to both fb and twitter. |
| 20:09 | AryehGregor | is reminded of why he isn't on Facebook too, then. |
| 20:09 | <TabAtkins> | I like the random unconnected thoughts. ^_^ |
| 20:09 | <TabAtkins> | And if someone is uninteresting enough, I just unfollow or hide them. |
| 20:10 | TabAtkins | just uses twitter for technical stuff and webcomic authors. |
| 20:13 | <TabAtkins> | AryehGregor: It also lets you know that, were you at my house, you'd be enjoying some damned fine fresh bread. |
| 20:18 | <gsnedders> | TabAtkins: Then why on earth do you follow me? :P |
| 20:19 | <TabAtkins> | gsnedders: Good question. ^_^ |
| 20:19 | <TabAtkins> | Nah, I *read* twitter for more than technical stuff, and you're high enough on my list of "internet friends" to be followable. |
| 20:20 | gsnedders | still doesn't get why so many people read his shit |
| 20:20 | <TabAtkins> | You don't post enough to be annoying, is why. |
| 20:35 | <dandaman> | this is a # for html5? |
| 20:35 | <TabAtkins> | Yes. |
| 20:35 | <dandaman> | is there an IDE someone can recommend? |
| 20:36 | <dandaman> | im just starting out html5 for this internship |
| 20:36 | <dandaman> | and i'd like to make the learning process as quick as possible |
| 20:36 | <TabAtkins> | I suggest a text editor. ^_^ |
| 20:36 | <AryehGregor> | HTML5 is just HTML+JavaScript+CSS. |
| 20:36 | <AryehGregor> | So use whatever HTML/JS/CSS IDE you want. |
| 20:36 | <AryehGregor> | (personally I just use a text editor) |
| 20:37 | <AryehGregor> | We probably are not the best people to ask questions like this, because we're all very familiar with HTML5 and don't really need IDEs or things like that. |
| 20:40 | <TabAtkins> | Yeah, syntax highlighting is about all the luxury I'm used to. |
| 20:40 | <karlushi> | dandaman, what do you use usually? |
| 20:44 | <dandaman> | i havent touched html for like 8 years, not since i was 8 |
| 20:44 | <dandaman> | 13* |
| 20:46 | <Martijnc> | dandaman: I use Notepad++, not really an IDE but is has syntax highlighting |
| 20:49 | <AryehGregor> | "This site is attempting to download multiple files. Do you want to allow this? Allow/Deny/X" |
| 20:49 | <AryehGregor> | 1) What does that actually mean? 2) Why would I want to not allow it? |
| 20:50 | <TabAtkins> | Yay for useless "security" prompts. |
| 20:50 | <AryehGregor> | (this URL in Chrome: http://www.mozilla.com/en-US/products/download.html?product=firefox-4.0b1&os=linux&lang=en-US) |
| 20:50 | <AryehGregor> | Downloads the same tar.bz2 for me twice . . . |
| 20:50 | <TabAtkins> | Doesn't for me. |
| 20:51 | <TabAtkins> | You're on dev channel, right? |
| 20:51 | <AryehGregor> | Yeah, on Linux. |
| 20:51 | AryehGregor | tries reloading |
| 20:51 | <TabAtkins> | I'm on normal linux, so that sounds like a bug. |
| 20:51 | <AryehGregor> | Doesn't reproduce when I reload. Although it downloads instantly, maybe If-Modified-Since or something. |
| 20:53 | <Martijnc> | It happens when you click 'click here' and the automatic download starts |
| 20:53 | <AryehGregor> | Ah, that explains it. |
| 20:53 | <AryehGregor> | No idea what the prompt is for, though . . . |
| 20:55 | <AryehGregor> | maxlength="140" for feedback is criminal. Is this being tweeted or something? |
| 20:57 | <AryehGregor> | Wow, Firefox 4 is really much snappier. |
| 20:58 | <AryehGregor> | Also, the feedback thing misdetected some slashes as the presence of URLs and rejected the input. |
| 21:25 | <hober> | is <noscript> currently conforming in the draft? |
| 21:25 | <TabAtkins> | Pretty sure yes. |
| 21:25 | TabAtkins | would have to check to be sure. |
| 21:25 | <AryehGregor> | Yes. |
| 21:26 | <TabAtkins> | Only in HTML, of course. |
| 21:26 | <AryehGregor> | There's a bug complaining about it. |
| 21:26 | <AryehGregor> | Lots of arguing, including at least one person who actually develops web pages for a living and seems to be encountering standards-purity advocates for the first time. |
| 21:26 | <crash\> | yeah <noscript> is obsolete, but we need it I think since it's widly used |
| 21:27 | <AryehGregor> | It's not really obsolete. |
| 21:27 | <crash\> | so it's good to have it standardized |
| 21:27 | <crash\> | AryehGregor: is there any use case for <noscript>? |
| 21:27 | <crash\> | I say it's easy, but scripting is better in all cases |
| 21:27 | <AryehGregor> | A page that consists of a JavaScript game, where all you want to do without script is say "You have to have JavaScript"? |
| 21:28 | <AryehGregor> | You can emulate the effect easily with script, but why bother? |
| 21:28 | <crash\> | since <noscript> has it's problems |
| 21:28 | <AryehGregor> | Like what? |
| 21:28 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068 |
| 21:29 | <AryehGregor> | See, someone who actually writes web pages for a living: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068#c20 |
| 21:30 | <crash\> | it's right what he says |
| 21:30 | <crash\> | but I say it's better to do alternate content via scripting |
| 21:31 | <crash\> | AryehGregor: like <noscript> doesn't have type |
| 21:31 | <AryehGregor> | Type? |
| 21:31 | <TabAtkins> | crash\: That's not a problem in practice. If the web ever actually develops a second scripting language that people care about, then maybe. |
| 21:31 | <AryehGregor> | Oh, yeah, that kind of type. Well, it just means "execute unless there's JavaScript support". |
| 21:31 | <AryehGregor> | If you have some other language you want to test for, go ahead and use script. |
| 21:32 | <AryehGregor> | It's not a realistic issue. |
| 21:32 | <crash\> | so you can't use it when you want it only be visible if a certain scripting langauge is availble |
| 21:32 | <AryehGregor> | Sure you can, as long as that scripting language is JavaScript. |
| 21:32 | <AryehGregor> | Which is the only one anyone uses or cares about in practice, so that's fine. |
| 21:33 | <crash\> | ok, good but <noscript> doesn't cover those cases |
| 21:33 | <TabAtkins> | ...which is fine, because no one cares about those cases. |
| 21:33 | <AryehGregor> | Which nobody cares about. |
| 21:33 | <AryehGregor> | And if they did, fine, so don't use it in those cases. |
| 21:33 | <AryehGregor> | That doesn't hurt its utility in the other 99.984% of cases. |
| 21:33 | <AryehGregor> | (I'm being generous) |
| 21:33 | <TabAtkins> | And/or we'd fix it at that point. |
| 21:33 | <AryehGregor> | Unlikely, since it can be trivially emulated. |
| 21:34 | <TabAtkins> | True, but it's possible. |
| 21:34 | <crash\> | sure, it wont be a problem for most of the cases |
| 21:34 | <crash\> | but you should know that <noscript> isn't perfect |
| 21:35 | <crash\> | replacing content via scripting is |
| 21:35 | <AryehGregor> | It's also true that <noscript> will not cook pizza for me. |
| 21:35 | <AryehGregor> | Nor will replacing content by scripting. |
| 21:35 | <AryehGregor> | Ergo, neither is perfect. |
| 21:35 | <TabAtkins> | Damn those HTML designers and their lack of foresight. |
| 21:35 | <AryehGregor> | Objecting to an element on the basis that it works perfectly fine for the uses it was intended to cover but doesn't cover some other things you'd like it to cover makes no sense. |
| 21:36 | <crash\> | but it's a great advantage that HTML5 cover many of cases oldes standard didn't |
| 21:37 | <crash\> | and is on the other side is a standardwhich covers a lot of real-life problems |
| 21:38 | Philip` | misreads that as standardwich, which sounds like an interesting variant on the common sandwich |
| 21:38 | <crash\> | and JavaScript has it's versions and implementations, so it might become a problem some day |
| 21:39 | <crash\> | so some day somebody may complain about <noscript>, who knows? ;) |
| 21:39 | <TabAtkins> | Philip`: You don't want a sandwich designed by a standard. |
| 21:39 | <TabAtkins> | crash\: And on that day we'll commence caring. ^_^ |
| 21:39 | <AryehGregor> | crash\, so you think that people should avoid <noscript> because someday someone might complain about it? |
| 21:39 | <AryehGregor> | That's a remarkably low standard. |
| 21:39 | <crash\> | I think it should be marked deprecated, yes |
| 21:40 | <AryehGregor> | Because someone might someday complain about it, or for some other reason? |
| 21:40 | <AryehGregor> | Because I haven't seen any practical reason yet that authors shouldn't use it. |
| 21:43 | <crash\> | and one thing I forget it's not XHTML compatible ;) |
| 21:43 | <AryehGregor> | Yet another thing no one cares about in real life. |
| 21:43 | <crash\> | I think there are many people who would like to send XML |
| 21:44 | <AryehGregor> | Not relative to the number of web authors. |
| 21:45 | TabAtkins | is, for some reason, gradually writing a library for quoting and indenting emails while respecting max-width constraints on lines. |
| 21:46 | <AryehGregor> | . . . |
| 21:46 | <AryehGregor> | Like a plugin for a mail program, or it just works on plain text? |
| 21:46 | <TabAtkins> | Just a few python functions for my own use on plain text. |
| 21:47 | <TabAtkins> | When I'm quoting from a spec and indenting with |, and then later adjusting the wording and thus changing line lengths, I want an easy way to automagically readjust all the lines to respect 70-char lines while keeping the |s in proper place. |
| 21:50 | <AryehGregor> | E-mail indentation is annoying. Too bad no one has invented a way of doing auto-wrapping in e-mail. Maybe you could even add other features at the same time. Actually, it would make the most sense to reuse an existing format. Come to think of it, does the WHATWG work on anything that might be useful here? |
| 21:50 | TabAtkins | wonders if this would be easier to just write by importing the text as Markdown and then writing some html-to-plaintext functions. |
| 21:53 | <hober> | TabAtkins: Emacs' M-q can do that, if you tell it about the | |
| 21:53 | <TabAtkins> | Ah, yes, Markdown'll do what I need if I mod it to accept | and # as blockquoting markers as well (it's sorta a CSSWG convention to use that for spec suggestions and spec quoting, respectively). |
| 21:53 | <TabAtkins> | hober: That'd mean I have to use emacs. |
| 21:53 | <hober> | :) |
| 21:59 | <Hixie> | JonathanNeal: different styles for different media should be done with different style sheets (or @media in a style sheet), i don't get why the AT vendors haven't gotten around to supporting that yet. |
| 21:59 | <gsnedders> | Hmm, did ES5 really change parseInt to disallow leading "0" to mean octal when no browser will change? Great! |
| 22:00 | <JonathanNeal> | Hi Hixie |
| 22:00 | <JonathanNeal> | Are you referring to my hidden accessible issue? |
| 22:01 | <Hixie> | JonathanNeal: i was just continuing our earlier conversation :-) |
| 22:01 | <AryehGregor> | Hixie, maybe because people then are forced to write different styles for different media, and they won't test the styles they write for uncommon media, so the site breaks if you try to use the styles in practice? |
| 22:02 | <annevk> | Hixie, what is your fifth priority? *curious* |
| 22:02 | <Hixie> | AryehGregor: well in practice they wouldn't need to write style sheets for anything but the one they do now, but they could do display:none on the stuff they want to leave for ATs |
| 22:02 | <Hixie> | ideally we wouldn't need to hide anything from non-ATs, too |
| 22:03 | <Hixie> | annevk: deal with feedback |
| 22:04 | <annevk> | nothing grand like <device>? :) |
| 22:05 | <Hixie> | <device> is 7th |
| 22:05 | <Hixie> | though i may work on it out-of-order on tuesday |
| 22:05 | <annevk> | heh |
| 22:05 | <Hixie> | since there's a lot of interest |
| 22:06 | <annevk> | I think most people outside are way past the process bullshit and are looking at what is next |
| 22:06 | <Hixie> | yes |
| 22:06 | <annevk> | and to be honest, me too, for the most of it |
| 22:06 | <Hixie> | me too :-) |
| 22:14 | <JonathanNeal> | Hixie, but even when I use @media to style the obscured elements (the hidden accessibles) I think I'll need the same tricks. |
| 22:15 | <AryehGregor> | In theory no. Just put display: none in the visual stylesheets, and not in the media-specific stylesheets. |
| 22:15 | <AryehGregor> | No tricks required. |
| 22:15 | <AryehGregor> | That doesn't work, but only because ATs use the visual stylesheets. |
| 22:17 | <JonathanNeal> | AryehGregor, oh ... yea I hate when practice beats theory, but that kinda binds me, yea. |
