| 09:13 | <MikeSmith> | zcorpan: if you're around, I'm wanted to ask a question about the script ABNF at http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements |
| 09:14 | <MikeSmith> | or Hixie, if you're around |
| 09:15 | <zcorpan> | if websocket unmasking key is SHA-1(uuid, server nonce, client nonce, per-frame key)? how would you know what to use as per-frame key to get 0 as unmasking key? |
| 09:15 | <zcorpan> | MikeSmith: what about it? |
| 09:17 | <MikeSmith> | zcorpan: so the need to check for is "<!--" without a later "-->" is clear, but I'm trying to remember what I need to do for the "<script and "</script" |
| 09:18 | <MikeSmith> | is it not sufficient to have a check for "</script" followed by space, "/", or ">"? |
| 09:19 | <MikeSmith> | I don't understand why the ABNF has the stuff about "script-start = lt s c r i p t tag-end" |
| 09:19 | <MikeSmith> | instead of just for script-end |
| 09:27 | <zcorpan> | so e.g. "foobar(data1) <!--(escape) foobar(data2) <script>(script-start) foobar(data3) </script>(script-end) foobar(data2) <script>(script-start) foobar(data3) --> foobar(data1)" should be valid if i'm reading the abnf correctly |
| 09:27 | <zcorpan> | i don't understand why [ script-start data3 ] is in the first row |
| 09:30 | <zcorpan> | i also don't understand why it has [ escape ] at the end |
| 09:31 | <MikeSmith> | yeah |
| 09:32 | <MikeSmith> | even if I could implement that as spec'ed, I have no clue what kind of end-user-friendly error message I could report that would actually be useful |
| 09:32 | <zcorpan> | maybe i'm reading the abnf wrong, because it seems bogus to me :) |
| 09:34 | <MikeSmith> | I'm not sure those constraints are useful for the sake of document validation anyway |
| 09:37 | <MikeSmith> | since you can't feed the validator a DOM |
| 09:37 | <MikeSmith> | but instead a serialized document |
| 09:39 | <zcorpan> | a validator could be operating on the dom level if it's a browser extension |
| 09:39 | <MikeSmith> | well |
| 09:39 | <MikeSmith> | it's not going to be executing script hopefully |
| 09:40 | <zcorpan> | the browser executes script |
| 09:40 | <MikeSmith> | ah |
| 09:43 | <MikeSmith> | that's already a problematic use case |
| 09:44 | <MikeSmith> | for one thing, reporting the locations of any errors |
| 09:46 | <zcorpan> | you could point to the node and clicking it highlights the node in dragonfly |
| 09:48 | <MikeSmith> | yeah, could, potentially |
| 09:49 | <MikeSmith> | but the backend doesn't yet have any means for enabling that |
| 09:56 | <zcorpan> | sure, validator.nu isn't built for that environment in mind |
| 09:57 | <zcorpan> | s/in mind// |
| 10:04 | <MikeSmith> | anyway, I implemented the core checks for "/*" without a later "/*" and "//", for the script/@src case, and "<!--" without a later "-->" for both the src-less script case and script/@src case |
| 10:05 | <MikeSmith> | and got it up now at http://www.w3.org/html/check |
| 10:07 | <zcorpan> | cool |
| 10:09 | <MikeSmith> | I hope hsivonen will have time soon for some reviewing |
| 10:10 | <zcorpan> | i think it'd be more useful if the spec had parse errors for bogus <!--<script> cases in the parser |
| 10:12 | <zcorpan> | MikeSmith: i can't test xhtml with http://www.w3.org/html/check ? |
| 10:12 | <MikeSmith> | yeah you can |
| 10:12 | <MikeSmith> | under Options |
| 10:12 | <zcorpan> | oh |
| 10:15 | <zcorpan> | <script></script></script> in xhtml is invalid according to the spec |
| 10:15 | <zcorpan> | but i don't think that's particularly useful to check for, personally |
| 11:22 | <Necra> | !loltip |
| 11:22 | <Necra> | oops |
| 11:29 | <MikeSmith> | zcorpan: I can't check for that in the datatype-checking code anyway |
| 11:30 | <MikeSmith> | because by the time it gets to that part of the code, "<" and "<" are the same |
| 11:38 | <zcorpan> | MikeSmith: so? the abnf bans the textContent "</script>" |
| 14:10 | <bga_> | i can not send mail to es-discuss⊙mo :( |
| 14:11 | <bga_> | i have sended mail twice, but it do not displays in discuss tree |
| 16:44 | <_bga> | http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/ |
| 17:01 | <webben> | Would it not make sense to allow microdata to take value from the .value property of form fields? http://www.w3.org/TR/microdata/#values |
| 17:02 | <TabAtkins> | Hm, that's interesting. The immediate problem I can see is that, in the course of normal web crawling, you'd often see the value as "". |
| 17:02 | <TabAtkins> | I suppose the use-case is to let the user fill out a form and then extract the Microdata from it automatically? |
| 17:07 | <webben> | TabAtkins: That's a use. |
| 17:08 | <webben> | TabAtkins: I was actually looking at it in the context of http://tech.groups.yahoo.com/group/rest-discuss/message/17135?threaded=1&var=1&l=1 |
| 17:09 | <webben> | TabAtkins: Which is discussing decorating HTML forms with RDFa semantics to decouple the domain vocabulary from the URL/form-encoding interface presented by the server and represented by @name |
| 17:09 | TabAtkins | is reading. |
| 17:09 | <webben> | TabAtkins: "<input id="case_title" name="Case.Title" property="dc:title"/>" does not work AFAICT |
| 17:10 | <webben> | TabAtkins: Since RDFa designates that dc:title is @content or the concatenation of text nodes. |
| 17:10 | <webben> | I thought maybe microdata could do this, but it doesn't look like it. |
| 17:10 | <TabAtkins> | It seems like the linked use-case is exactly the use-case I described. |
| 17:12 | <webben> | TabAtkins: Well if your use-case includes a programmer building a client to use the form, then yes. |
| 17:12 | <TabAtkins> | Which appears to be the described use-case, yes. |
| 17:12 | <webben> | ah ok |
| 17:13 | <TabAtkins> | Yeah, it seems to just be aiming for something that makes it easy to both extract the data client-side and server-side. Presumably there's already a framework server-side to convert the received form data into a more useful format. |
| 17:14 | <TabAtkins> | I'm not really sure what the value is of making @name and @property be different things. |
| 17:14 | <webben> | Well, it allows to use arbitrary @name's. |
| 17:15 | <TabAtkins> | Yes. So what's the value of that? |
| 17:15 | <webben> | Well, it allows you to present a consistent interface across different ways of processing name=value pairs. |
| 17:16 | <webben> | (For example, in PHP land, people tend to use foo[] for repeated values, but there's nothing baked into CGI about that.) |
| 17:16 | <TabAtkins> | How? There are only two ways I can see here - extracted as Microdata/RDFa on the client side, and received as name/value pairs on the server side. |
| 17:16 | <TabAtkins> | Those don't seem consistent unless you go to efforts to make them consistent. |
| 17:17 | <webben> | TabAtkins: I think the idea is the serverside processing and URLs could completely change, while clientside processing would persist. |
| 17:18 | <webben> | So for example you could change the @names and types of form attributes, but the client would persistently look for dc:title |
| 17:18 | <webben> | *of form fields |
| 17:19 | <TabAtkins> | Is there any good reason for this, though? Surely you could add an interpretation layer on the serverside that translates the kv pairs to whatever you needed? |
| 17:20 | <webben> | TabAtkins: Sure. Additional layers of processing doesn't sound more efficient than a persistent client interaction though. |
| 17:21 | <TabAtkins> | Sure. I'm just wondering about the utility of that. Extra indirection (a single piece of data referred to through two names) needs to be justified. |
| 17:22 | <webben> | TabAtkins: Well, at least it offers the potential to use a specific name (e.g. dc:title) rather than what's basically an opaque string (@name) |
| 17:22 | <webben> | s/specific/generically understood/ |
| 17:23 | <TabAtkins> | @property is an opaque string as well. It has exactly as much meaning as @name, until you add meaning to it. |
| 17:23 | <webben> | TabAtkins: You can't reference a specific vocabulary via @name can you? |
| 17:24 | <TabAtkins> | Sure. I can put <input name="dc:title"> in my page. |
| 17:24 | <TabAtkins> | No current processor will recognize it as a curie, but I could do it. |
| 17:24 | <webben> | TabAtkins: That's still an opaque name in the absence of rules like microdata or RDFa for extracting it. |
| 17:24 | <TabAtkins> | Sure. Rules could be added if necessary, of course. |
| 17:25 | <webben> | Yes. It /might/ be that at least part of this usage could be addressed by providing such rules. |
| 17:26 | <webben> | I'm not sure there any standardizable way to map such vocabularies to a query string though. |
| 17:26 | <TabAtkins> | Hm? Of course there is. ?dc:title=foo |
| 17:27 | <webben> | TabAtkins: How about nested keys? |
| 17:27 | <TabAtkins> | You can't express that in forms. |
| 17:30 | <webben> | TabAtkins: well, you can ... e.g. name="book[4]title" |
| 17:30 | <TabAtkins> | Ah, yeah, sure, you can do server-side processing. |
| 17:30 | <webben> | exactly |
| 17:31 | <webben> | providing an independent mapping of the HTML representation to a shared vocabulary allows you to decouple the details of that processing from the client code. |
| 17:32 | <TabAtkins> | Hm, okay, I see your point. Trying to automatically express the relationship in the key sent over the wire is probably a harder problem than just letting people express it twice themselves (once explicitly in the @name, once implicitly in the microdata structure). |
| 17:32 | <webben> | I suspect so. |
| 17:40 | <webben> | TabAtkins: I think the point about value beginning in an invalid form (e.g. "" for a non-null data type) is a problem though. |
| 17:41 | <webben> | TabAtkins: I guess in so far as HTML5 can express data types/validity without script, extraction of data rather than extraction of input points could be premised on validity. |
| 17:41 | <TabAtkins> | Hm, that's true. |
| 17:42 | <TabAtkins> | But that would mean that, for example, non-required inputs would still be included. |
| 17:43 | <webben> | Excluding blank values might be possible; or including blank values might not be damaging - I'm not sure. |
| 18:42 | <matjas> | TabAtkins: [post] - [site] fo’ sho’! |
| 18:43 | <TabAtkins> | matjas: That's what I was thinking. [site] - [post] is only for corporate branding - I find putting the post first is a lot more attractive for blogs. |
| 18:44 | <matjas> | TabAtkins: replied on Twitter as well, but [p] - [s] is definitely the most useful variant if you consider small tab sizes (like in Chrome) |
| 18:55 | <webr3> | why not just [title] |
| 18:57 | <TabAtkins> | That makes it harder to, frex, remember where a bookmark came from. |
| 18:57 | <TabAtkins> | Anyway, done. |
| 18:57 | <matjas> | Yay! |
| 18:58 | <TabAtkins> | Also exposed a bug where I wasn't setting rel=canonical properly. I've rearchitected slightly to make future bugs of this sort less likely. |
| 19:25 | <matjas> | TabAtkins: heh, your site doesn’t work without the www. |
| 19:26 | <TabAtkins> | matjas: Indeed. That's the default for my provider - they seem to have a religious thing against it. I haven't cared enough to set it up differently. |
| 19:43 | <TabAtkins> | Hixie: Any reason why the section on CSS pseudoclasses only mentions a restricted list of elements that can match :active, when in practice all browsers allow all elements to be :active while they are clicked? |
| 20:30 | <Hixie> | TabAtkins: iirc it was based on a request of the csswg, but honestly i don't recall |
| 20:30 | <Hixie> | well |
| 20:32 | <annevk> | TabAtkins, wow, your provider is silly |
| 20:32 | <annevk> | TabAtkins, get DreamHost :) |
| 20:33 | <Hixie> | dreamhost are pretty silly too |
| 20:33 | <Hixie> | though maybe in a different way |
| 21:00 | <TabAtkins> | Hixie: I suspect it was a request from fantasai, since she dislikes the idea of arbitrary elements being activatable. |
| 21:01 | <TabAtkins> | Hixie: In any case, all browsers allow all elements to be :active. |
| 21:01 | <TabAtkins> | I can file a bug if it would help. |
| 21:04 | <Hixie> | TabAtkins: yeah, file a bug or send e-mail. IE didn't used to do this like the others. |
| 21:05 | <TabAtkins> | Yeah, but they didn't use to do :hover on non-links either. |
| 21:05 | <TabAtkins> | Will file. |
| 21:05 | <Hixie> | so? |
| 21:05 | <Hixie> | we're talking about :active, not :hover :-) |
| 21:05 | <Hixie> | if we do change this we'll have to define what :active means |
| 21:05 | <TabAtkins> | Right, but they're done through similar events, and conceivably are handled similarly in the browser. |
| 21:05 | <Hixie> | and how to do it from the keyboard |
| 21:06 | <TabAtkins> | You still can't activate arbitrary elements from the keyboard, unless they're tab-able or something. |
| 21:07 | <Hixie> | that seems suboptimal |
| 21:10 | <TabAtkins> | Huh. IE8 & 9 let any element be activated, but only the target of the click gets :active, not everything up the chain. |
| 21:11 | <bga_> | http://twitter.com/bga_/status/19863944524988416 :P |
| 21:12 | <bga_> | may be js not must know this. may be its security issue |
| 21:14 | <TabAtkins> | Bah, I can't be bothered to find the html bugzilla again. I'll just email. Same diff. |
| 21:26 | <TabAtkins> | Aren't there already some slightly hacky ways to force the event loop to spin in the middle of code? (Without breaking the code up and using setTimeout, that is.) |
| 21:34 | <TabAtkins> | (I'm thinking something involving databases has this effect.) |
| 21:35 | <Hixie> | (fwiw, i use the same mechanism for e-mail and bugs now, so it really makes no difference to me) |
| 21:36 | <TabAtkins> | Hixie: Yeah, I know, that's why I did it. |
| 21:36 | <Hixie> | this xml/html tf is baffling to me |
| 21:36 | <Hixie> | they were created to figure out what problem they were created to figure out? |
| 21:36 | <Hixie> | the w3c is getting dangerously close to poe's law |
| 21:36 | <TabAtkins> | No, they were created to make HTML act more like XML. Nobody wants to admit it, though. |
| 21:36 | <Hixie> | we already did that in the whatwg |
| 21:36 | <Hixie> | years ago |
| 21:37 | <Hixie> | html is closer to xml than it ever has been |
| 21:37 | <TabAtkins> | But the namespaces, Hixie! THE NAMESPACES! |
| 21:37 | <Hixie> | the namespaces are issue 41 |
| 21:37 | <Hixie> | it seems premature to do anything while we're still waiting for teh chairs to decide on that |
| 21:37 | <TabAtkins> | Yup. |
| 21:48 | <karlcow> | I became insane, with long intervals of horrible sanity. |
| 22:10 | <TabAtkins> | annevk: Looks like my provider added a one-click option for allowing bare domains since I last checked. It automatically issues a 301 to the www. version, which is fine with me. |
| 22:13 | annevk | prefers without redundant characters |
| 22:13 | <TabAtkins> | I don't particularly care either way, I just want a canonical url for the google juice. |
| 22:13 | <annevk> | that is, long ago I bought into http://no-www.org/ |
| 22:16 | <TabAtkins> | Doing what I just did (auto-redirect from bare to www) is compatible with no-www philosophy. |
| 22:16 | <TabAtkins> | I agree that not allowing the bare name isn't ideal. I only left it like that because I was lazy. |
| 22:17 | <TabAtkins> | Hehe, I love extra-www.org |
| 22:20 | <annevk> | I guess it is, yes, just seems like waste |
| 22:20 | <TabAtkins> | I don't understand what's being wasted. |
| 22:20 | <annevk> | characters :) |
| 22:21 | <annevk> | either characters or an additional request |
| 22:21 | <TabAtkins> | I don't understand how chars are wasted - people can still type/link the bare domain name. |
| 22:21 | <TabAtkins> | The additional request is required in one direction or the other, so I don't see much distinction about which direction it goes in. |
| 22:23 | <kennyluck> | huh. http://yes-www.org/ returns 403 while http://www.yes-www.org/ works |
| 22:23 | <TabAtkins> | Clearly they're doing the Hardcore option. |
| 22:24 | <karlcow> | one or the other it doesn't seem that important. How many type really type the letters of the domain name |
| 22:24 | <TabAtkins> | Yeah, I mean I just type "FACEBOOK LOG ME IN" into google. |
| 22:24 | <karlcow> | houla my usual dislexya |
| 22:25 | <karlcow> | how many time |
| 22:25 | <karlcow> | people |
| 22:25 | <karlcow> | geeez |
| 22:25 | <annevk> | actually TabAtkins, your site is not correct per no-www |
| 22:26 | <annevk> | not that it matters |
| 22:26 | <TabAtkins> | Hm? |
| 22:27 | <annevk> | check the validator |
| 22:27 | <TabAtkins> | Yeah, it won't work yet. I just made the DNS change, like, ten minutes ago. |
| 22:28 | <karlcow> | surprised nobody proposed worldwideweb.example.org |
| 22:51 | <karlcow> | another useless campaign http://www.antiifcampaign.com/ |
| 22:51 | <TabAtkins> | Actually, that's not a bad campaign idea. |
| 22:52 | <karlcow> | it's poetic |
| 23:01 | <Philip`> | Seems a misleading name - it's not anti-if, it's just anti if-over-type-identifiers-as-a-cheap-substitute-for-polymorphism |
| 23:07 | karlcow | hesitates to launch the goto-back-campaign.com :p |
| 23:12 | <karlcow> | but for now I guess I will do the less-have-a-wonderful-dinner.com |
| 23:32 | <TabAtkins> | annevk: You're hopefully asleep by now, but could you respond to the "What to include in a propdef" thread on the csswg private list? |