| 00:06 | <TabAtkins> | Hixie: you mean 7.7 now, which starts with "Apply the terms of the CSS specifications..."? |
| 00:06 | <Hixie> | yeah |
| 00:08 | <TabAtkins> | That feels adequate to me. |
| 00:08 | <Hixie> | cool, thanks |
| 00:09 | <Hixie> | anything i should improve? |
| 00:09 | <TabAtkins> | It looks like the internal node objects can still be accessed by using * to select things? |
| 00:10 | <cardona507> | hmmm - what are the chances that we will move to a similar model as HTML and just have one version of CSS? |
| 00:10 | <Hixie> | TabAtkins: "No style sheets are associated with /nodes/" |
| 00:10 | <Hixie> | cardona507: about nil, in practice, but we can hope... |
| 00:15 | <variable> | general proccess question: I brought up a couple of ideas on the mailing list (input type="username" as one example) which were discussed and then the thread died. Does that mean that the ideas were rejected or am I supposed to do something more than that? |
| 00:15 | <Hixie> | neither |
| 00:15 | <Hixie> | eventually i'll get to the thread |
| 00:16 | <Hixie> | and then i reply to it, either adding the feature or something like it, or explaining what arguments were convincing |
| 00:16 | <Hixie> | the list of e-mails i haven't yet responded to is here: http://www.whatwg.org/issues/ |
| 00:19 | <Hixie> | (i'm way behind -- there's a graph of my progress here: http://www.whatwg.org/issues/data.html) |
| 00:20 | <TabAtkins> | Hixie: Hm, I guess that works. How are you then hooking up later stylesheets that'll be accessing things through ::cue() pseudos? |
| 00:20 | <KrocCamen> | Wow, what was with that crazy productive week in October? |
| 00:21 | <variable> | Hixie, the particular example I mentioned isn't on that list |
| 00:21 | <variable> | (I'm not just trying to bump the queue or anything - just trying to understand how things work) |
| 00:21 | <Hixie> | TabAtkins: the bit that says "All properties have their initial values, except as explicitly overridden for specific nodes in the next section" is my hook to define those things, which i'll do in the next couple of sections |
| 00:22 | <Hixie> | KrocCamen: i needed to get to zero so we could announce last call, so i worked my ass off :-) |
| 00:22 | <Hixie> | variable: do you have a subject line? let me check what's up with it |
| 00:22 | <Hixie> | variable: when did you send it? |
| 00:23 | <variable> | RFC: <input type="username"> may 4th |
| 00:23 | <TabAtkins> | Hixie: My question, though, is how you're supposed to associate stylesheets with those nodes in the first place, when you're explicitly saying there mustn't be any? |
| 00:24 | <KrocCamen> | A username could be an email BTW. |
| 00:24 | <KrocCamen> | Just to throw a spanner in the works. |
| 00:25 | <variable> | KrocCamen, that was brought up during the thread |
| 00:25 | <variable> | my response was that the lists of emails the browser should be using are different. If the username == email address I don't want the browser to start offering Bob's email address if my username is bannanna |
| 00:26 | <variable> | The semantics are different. In one case the system wants an email address, in the othercase the system wants a username that just happens to be in the pattern of an email |
| 00:27 | <Hixie> | TabAtkins: i explicitly assign the properties myself in the subsequent sections |
| 00:27 | <KrocCamen> | Mozilla have been looking to move identity into the browser including a system for sites to specify their login pages so the browser can handle the login and manage identities. |
| 00:27 | <Hixie> | TabAtkins: rather than letting the css do it |
| 00:27 | <Hixie> | the css spec do it, i mean |
| 00:27 | <Hixie> | (since the css spec doesn't know about the pseudos) |
| 00:28 | <TabAtkins> | Hixie: Hrm. That seems kind of silly, though. |
| 00:28 | <variable> | KrocCamen, also brought up in the thread ;) I don't remember if I was the first one to mention that or not. |
| 00:28 | <variable> | IMHO The mozilla project is loooong overdue. |
| 00:28 | <Hixie> | TabAtkins: how else can we do it? |
| 00:29 | <variable> | I only brought the issue up now to understand how the whatwg proccess works.... |
| 00:29 | <Hixie> | variable: it's there |
| 00:29 | <Hixie> | under processing-model |
| 00:30 | <Hixie> | (sorry, took me a while to find it) |
| 00:30 | <variable> | Hixie, no problem. Which category is it under? |
| 00:30 | <TabAtkins> | Hixie: Just handle it through normal CSS matching rules, defining what pseudos match what functions. The only downside is the ability of * to match, but that can probably be hacked around. |
| 00:30 | <Hixie> | (e-mails 318 to 346 in that folder, when sorted in the order i go through them by, which is by thread sorted by date of first e-mail) |
| 00:30 | <Hixie> | variable: processing-model |
| 00:31 | <TabAtkins> | And even if we left it alone, rules don't flow into embedded documents normally. |
| 00:31 | <Hixie> | TabAtkins: i don't really understand how that would be a any different in practice |
| 00:31 | <variable> | Hixie, alright - sorry for bothering you :D |
| 00:31 | <Hixie> | variable: np! |
| 00:32 | <TabAtkins> | In practice, it shouldn't be. It just seems weird to try and end-run around CSS matching when you're going to duplicate it anyway. |
| 00:32 | <Hixie> | TabAtkins: well basically my choice is between saying we skip the css matching and i do it, or saying we do the css matching but then overrulling every single part of it. |
| 00:33 | <Hixie> | TabAtkins: i don't see the win of doing it the other way... but maybe i should spec out what i had in mind and then you can look at that and show me what you mean and if it's better i'll use that instead :-) |
| 00:34 | <TabAtkins> | Heh, kk. I'm curious, though - are you just afraid of people trying to match against the doc with "* > * + * { color: red; }" or something? |
| 00:37 | <Hixie> | TabAtkins: no, i just thought it'd be clearer if i did it this way |
| 00:37 | <TabAtkins> | I think just making it an embedded document like "normal" is the clearest, personally. |
| 00:38 | <Hixie> | you'll be able to demonstrate this for me once i've figured out what the pseudo is gonna look like :-) |
| 00:38 | <TabAtkins> | kk |
| 00:38 | <Hixie> | is 'vh' allowed yet btw? |
| 00:38 | <Hixie> | i'm using it to define the default font size of cues |
| 00:39 | <TabAtkins> | It's in Units 3. So... yes? |
| 00:39 | <Hixie> | i mean is units 3 stable? |
| 00:39 | <Hixie> | it was in WD last i checked |
| 00:40 | <TabAtkins> | Still is. |
| 00:40 | <Hixie> | but i don't know what that means w.r.t. stability |
| 00:40 | <Hixie> | k |
| 00:41 | <TabAtkins> | But vh and friends are liked and have no plans to change or be removed, afaik. |
| 00:41 | <Hixie> | ooh, 'fr' |
| 00:41 | <Hixie> | that is... woefully underspecified |
| 00:41 | <TabAtkins> | Yeah, don't rely on that one yet. |
| 00:41 | <TabAtkins> | It's recent. |
| 00:41 | <Hixie> | k |
| 00:42 | <TabAtkins> | And subject to change when we decide on what to do with Flexbox. |
| 00:44 | <Hixie> | is there a font-outline or any such thing? |
| 00:44 | <TabAtkins> | Not outside of -webkit-text-stroke |
| 00:44 | <Hixie> | i found text-outline in css3 text, is that dead? |
| 00:45 | <TabAtkins> | Not dead - temporarily sedated until a team of medical personell can treat it. |
| 00:45 | <Hixie> | hah |
| 00:45 | <Hixie> | k |
| 00:47 | <Hixie> | is there any way of absolutely forcing text wrapping at the viewport width? |
| 00:47 | <Hixie> | even if it's half-way through a word? |
| 00:48 | <Hixie> | we were talking about white-space: emergency or something a while back |
| 00:48 | <Hixie> | but i can't see anything like that |
| 00:48 | <TabAtkins> | What case are you thinking about, more specifically? You mean if an element would normally be wider than the viewport, but you still want it to be wrapped by the viewport? |
| 00:49 | <Hixie> | i don't mind setting max-width |
| 00:49 | <Hixie> | i just want to make sure the cues wrap and don't go off the edge of the video |
| 00:49 | <Hixie> | even if they are just one long string of letters |
| 00:49 | <TabAtkins> | Oh, so if you've already forced a word to its own line and it's still too long, doing a forced break in the middle of the word? |
| 00:49 | <Hixie> | yeah |
| 00:50 | <TabAtkins> | Nothing for that exists right now. |
| 00:50 | <Hixie> | k |
| 00:50 | <Hixie> | i'll just use prose then |
| 00:50 | <eseidel> | where is teh Henri |
| 00:50 | <eseidel> | </foreignObject> is impossible ;p I must understand how he haxored it |
| 00:50 | <Hixie> | paging hsivonen for eseidel |
| 00:50 | <eseidel> | dr. hsivonen! |
| 00:51 | <Hixie> | i seem to recall whatever he did is described in the relevant bug btw |
| 00:51 | <Hixie> | and that i looked at it and decided it was sane |
| 00:51 | <eseidel> | hsivonen: see my mail to you and hixie just now. I don't undersatnd how one ever is supposed to get out of the secondary insertion mode, once in it |
| 00:51 | <eseidel> | Hixie: I didn't find a bug on it |
| 00:52 | <Hixie> | 9580 to 9582? |
| 00:52 | <Hixie> | 9831 |
| 00:52 | <Hixie> | ? |
| 00:52 | <Hixie> | 10055? |
| 00:52 | <Hixie> | i'm sure it's one of those :-) |
| 00:52 | <Hixie> | no mail from you yet |
| 00:53 | <Hixie> | unless you sent it to my work address |
| 00:53 | <Hixie> | ah here it is indeed |
| 00:56 | <eseidel> | Hixie, hsivonen: I'm just not sure what condition is supposed to kick you out of secondary insertion mode? I assume handling </foreignObject> |
| 00:56 | <eseidel> | but In Body mode doesn't talk about </foreignObject> :) |
| 00:57 | <Hixie> | the spec is known buggy here |
| 00:57 | <Hixie> | i think it's 9582 |
| 00:57 | <Hixie> | a few more days and i'll be able to go through all these bugs and fix them |
| 00:57 | <Hixie> | i'm almost done with subtitles |
| 00:58 | <eseidel> | nah, I don't think it's 9582 |
| 01:08 | <eseidel> | Hixie: I'm not sure how hsivonen handled it, but AFAICT he hasn't filed a bug on it. I'll track him down later |
| 01:09 | <Hixie> | k |
| 01:09 | <Hixie> | please file a bug and mark it P1/crit when you work out how to fix it (or even before -- i'm likely to look at this on wednesday if all goes according to plan) |
| 01:15 | <MikeSmithX> | /me just now notices that spec currently says that the values of on* event-handler attributes "must contain valid JavaScript code matching the FunctionBody production. [ECMA262]" |
| 01:15 | <MikeSmithX> | http://dev.w3.org/html5/spec/webappapis.html#event-handler-content-attributes |
| 01:16 | <MikeSmith> | that's not going to be much fun to try to validate |
| 01:16 | <MikeSmith> | I wonder if there might be some way to validate it using Rhino |
| 01:20 | <MikeSmith> | or could use JSLint to check it maybe |
| 01:21 | <MikeSmith> | geez |
| 01:23 | <MikeSmith> | is it really still the case that there's no HTML version of the ecmascript spec? |
| 01:28 | <MikeSmith> | http://twitter.com/heycam/status/18393872430 |
| 01:29 | <MikeSmith> | "Excited to say that from October, I'll be moving to NZ and working for Mozilla on Platform & standards stuff from their Auckland office!" |
| 01:29 | <MikeSmith> | w00t |
| 01:29 | MikeSmith | looks forward to heycam getting back on IRC |
| 01:30 | boblet | didn’t know Moz had an AK office |
| 01:30 | <MikeSmith> | boblet: really? |
| 01:31 | <boblet> | rly |
| 01:31 | <boblet> | (not that I’ve ever lived there mind) |
| 01:31 | <MikeSmith> | ah |
| 01:31 | <MikeSmith> | well, roc's there |
| 01:31 | <MikeSmith> | I think still |
| 01:32 | <MikeSmith> | and I think doublec too |
| 01:32 | <doublec> | yep, I'm there too |
| 01:32 | <MikeSmith> | doublec: you have a fair number of people there, right? |
| 01:33 | <doublec> | 5 at the moment |
| 01:33 | <doublec> | kinetik is there too |
| 01:33 | <boblet> | へー |
| 01:33 | <boblet> | my image of AK improves :) |
| 01:33 | <doublec> | :) |
| 01:35 | <MikeSmith> | didn't know kinetik was there too |
| 01:38 | <MikeSmith> | the EcmaScript spec PDF would be just slightly less of a PITA to try to read if it actually had hyperlinks at least |
| 01:40 | <MikeSmith> | "The production FunctionBody : SourceElementsopt … 2. |
| 01:40 | <MikeSmith> | If SourceElements is present return the result of evaluating SourceElements" |
| 01:41 | <MikeSmith> | so there's no actual grammar for SourceElements? |
| 01:41 | <Hixie> | and you thought the HTML5 spec was obtuse :-P |
| 01:42 | <Hixie> | SourceElements is further defined |
| 01:42 | <Hixie> | page 222 |
| 01:42 | <Hixie> | just below the definition of FunctionBody |
| 01:42 | <Hixie> | and Program |
| 01:42 | <MikeSmith> | ok |
| 01:42 | MikeSmith | takes another look |
| 01:43 | <Hixie> | it's defined in terms of SourceElement and SourceElement is defined on page 100 |
| 01:43 | <Hixie> | in terms of FunctionDeclaration |
| 01:43 | <MikeSmith> | ah, OK |
| 01:43 | <MikeSmith> | I see now |
| 01:43 | <Hixie> | that's on page 97 |
| 01:43 | <Hixie> | etc |
| 01:43 | <Hixie> | good luck!!! |
| 01:43 | <Hixie> | :-) |
| 01:44 | <Hixie> | once you've done this you'll be 90% of the way to a validator for <script type="text/javascript"> and .js files |
| 01:45 | <MikeSmith> | yippee |
| 01:47 | <MikeSmith> | we could reach 100% on validating event-handler attribute values if that constraint weren't stated in the spec :) |
| 01:47 | <MikeSmith> | I think you snuck that one in somehow |
| 01:47 | <MikeSmith> | while everybody was sleeping |
| 01:47 | <MikeSmith> | or while I was at least |
| 01:52 | <Hixie> | isn't it in HTML4 too? |
| 01:53 | <Hixie> | i mean i'm sure HTML4 doesn't state it quite so explicitly, but surely an HTML4 document isn't fully conforming if it has an event handler attribute whose value isn't valid in the relevant scripting language |
| 01:55 | <MikeSmith> | yeah, I suppose |
| 01:56 | <MikeSmith> | anyway, for now I've just filed a v.nu bug |
| 01:57 | <MikeSmith> | http://bugzilla.validator.nu/show_bug.cgi?id=756 |
| 02:00 | <MikeSmith> | I guess we ultimately should have some means for checking CSS in text content and attributes as well |
| 02:00 | <MikeSmith> | which could be done through an API to a CSS checker |
| 02:02 | <MikeSmith> | but that will require a CSS checker that's up to date with a complete version of the syntax spec for CSS, which in turn will require an editor actively working on such that spec to make it complete |
| 02:04 | <Hixie> | man i hate how the i-beam becomes basically invisible in Terminal.app when i have a black background |
| 02:06 | <MikeSmith> | yeah |
| 02:06 | <MikeSmith> | Hixie: I have the same problem |
| 02:06 | <MikeSmith> | I wonder if there is some way to make it fatter or blinkier |
| 02:06 | <MikeSmith> | I guess it would have to be system-wide |
| 02:07 | <MikeSmith> | but I could live with that at least |
| 02:08 | <MikeSmith> | I've even tried doing the option-command-control-8 thing to reverse colors |
| 02:08 | <MikeSmith> | but that actually never seems to help much |
| 02:09 | <Hixie> | you can make it fatter but then you just have an invisible big i-beam |
| 02:09 | <Hixie> | instead of an invisible small i-beam |
| 02:09 | <Hixie> | also it pixelates in a very un-apple-like manner |
| 02:46 | <eseidel> | bugz :( http://www.w3.org/Bugs/Public/show_bug.cgi?id=10139 |
| 02:50 | <eseidel> | Hixie: filed the </foriegnObject> bug for you. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10140, thanks. |
| 04:04 | <eseidel> | hsivonen: drop me a line when you're back around, I'd love to chat |
| 06:06 | <GPHemsley> | What is the content area of an <iframe> for? |
| 06:09 | <MikeSmith> | Closure Compiler seems to have an API that could be used for doing Javascript syntax checking |
| 06:09 | <MikeSmith> | http://code.google.com/closure/compiler/docs/api-ref.html |
| 06:10 | <MikeSmith> | throw some JS at it along with the output_info=errors param |
| 06:11 | <MikeSmith> | Yudai: ! |
| 06:11 | <MikeSmith> | I got a super-fun va. |
| 06:11 | <Yudai> | MikeSmith: what's up? |
| 06:11 | <MikeSmith> | I got a super-fun validator.nu enhancement for you to consider |
| 06:12 | <MikeSmith> | this is absolutely the funnest and bestest one that has come along in a long time |
| 06:12 | <Yudai> | above uri? |
| 06:12 | <GPHemsley> | uh oh... the info links on this page are missing their filename (and the resulting ".html" is forbidden): http://dev.w3.org/html5/markup/common-attributes.html |
| 06:12 | <MikeSmith> | GPHemsley: work in progress |
| 06:13 | <GPHemsley> | oh |
| 06:13 | <GPHemsley> | ok |
| 06:13 | <MikeSmith> | known issue with the build I use to make that doc |
| 06:13 | <MikeSmith> | will get it fixed this week |
| 06:13 | <GPHemsley> | what about the iframe question? :) |
| 06:13 | <Yudai> | MikeSmith: ah i see, it supports js syntax checking |
| 06:13 | <MikeSmith> | Yudai: the spec says this - |
| 06:14 | <MikeSmith> | http://dev.w3.org/html5/spec/webappapis.html#event-handler-content-attributes |
| 06:14 | <MikeSmith> | Event handler content attributes, when specified, must contain valid JavaScript code matching the FunctionBody production. [ECMA262] |
| 06:14 | <MikeSmith> | but we are currently not checking that |
| 06:14 | <MikeSmith> | "event handler content attributes" = onclick, etc. |
| 06:15 | <MikeSmith> | so we need to check the values of those and make sure they are valid JS |
| 06:15 | <Yudai> | yeah |
| 06:15 | <MikeSmith> | so, we'd need to add a new datatype to the v.nu HTML5 datatype libary |
| 06:15 | <MikeSmith> | *library |
| 06:15 | <Yudai> | it's easy way to call an external service to validate |
| 06:15 | <MikeSmith> | yeah |
| 06:16 | <MikeSmith> | kinda like we are already doing for IRI checking |
| 06:16 | <Yudai> | but it also may make some problems |
| 06:16 | <MikeSmith> | true |
| 06:16 | <MikeSmith> | but easier than trying to write a JS validator from scratch ourselves |
| 06:16 | <MikeSmith> | at least for prototyping |
| 06:16 | <MikeSmith> | so... We |
| 06:16 | <Yudai> | the IRI checking library is given as a static java library |
| 06:17 | <Yudai> | but this is a web service, right? |
| 06:17 | <MikeSmith> | yeah, afaict |
| 06:17 | <MikeSmith> | though there may be some way to use it as a normal library as well |
| 06:17 | <Yudai> | if we can have its source codes, that's great |
| 06:17 | <Yudai> | yeah |
| 06:18 | <MikeSmith> | source is here: http://code.google.com/p/closure-compiler/source/browse/#svn/trunk/src/com/google/javascript |
| 06:18 | <Yudai> | cool |
| 06:19 | <MikeSmith> | I don't know how conformant its JS syntax-checking is |
| 06:19 | <MikeSmith> | but it would give us something to test with |
| 06:19 | <Yudai> | ah, we might be able to use rhino |
| 06:19 | <MikeSmith> | we could us it as a prototype for the event-handler-value-checking feature, at the very least |
| 06:20 | <Yudai> | closure-complier seems also using rhino...at first glance |
| 06:21 | <MikeSmith> | yeah, saw that. I looked through rhino docs, but could not find any API that rhino exposes for parsing and reporting of syntax errors |
| 06:21 | <MikeSmith> | but there may be something in there |
| 06:21 | <MikeSmith> | anyway, it's something worth exploring, I guess |
| 06:21 | <Yudai> | yeah, i agree |
| 06:21 | <MikeSmith> | we can get hsivonen thoughts on it later when he gets on |
| 06:22 | <MikeSmith> | Yudai: bug I raised for this is here: |
| 06:22 | <MikeSmith> | http://bugzilla.validator.nu/show_bug.cgi?id=756 |
| 06:23 | <Yudai> | yeah |
| 06:49 | <MikeSmith> | Hixie: about http://bugzilla.validator.nu/show_bug.cgi?id=755 |
| 06:49 | <MikeSmith> | "Validator considers hidden inputs unlabelable" |
| 06:50 | <MikeSmith> | I find in http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute the statement, "Elements that are not hidden should not link to or refer to elements that are hidden" |
| 06:51 | <MikeSmith> | which is I think the reason why the v.nu code is currently treats a label reference to a hidden input element as a conformance error |
| 06:51 | <Peter`> | Mind that the Chairs still have to make a decision about removing or keeping @hidden |
| 06:51 | <Peter`> | issue 95 |
| 06:51 | <MikeSmith> | yeah |
| 06:51 | <MikeSmith> | Hixie: just wondering if that is in fact the intent of that statement in the spec |
| 07:03 | <GPHemsley> | How come <iframe> doesn't have @srctype or @type? |
| 07:12 | <Slaanesh> | GPHemsley: What benefit would that give? Seems like it would either be redundant or wrong. |
| 07:13 | <GPHemsley> | Slaanesh: to determine if a UA can support the iframed file |
| 07:13 | <GPHemsley> | I'm writing an e-mail to the list to discuss it |
| 07:13 | <GPHemsley> | (FYI) |
| 07:27 | <GPHemsley> | e-mail sent: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027113.html |
| 07:32 | <GPHemsley> | MikeSmith: What does the "agroupof" class mean? |
| 07:36 | <MikeSmith> | GPHemsley: it comes from the RelaxNG schema I use to build the content-model parts of the doc |
| 07:37 | <MikeSmith> | it means the enclosed contents are defined as a group in the schema |
| 07:37 | <GPHemsley> | does it make any difference to the web author? |
| 07:38 | <MikeSmith> | I think it does in some cases |
| 07:38 | <MikeSmith> | if the contents are ORed |
| 07:38 | <GPHemsley> | oh |
| 07:38 | <GPHemsley> | but not ANDed? |
| 07:40 | <MikeSmith> | maybe that too |
| 07:40 | <MikeSmith> | though there is not really and AND in RelaxNG |
| 07:40 | <Hixie> | MikeSmith: not sure what you mean |
| 07:41 | <MikeSmith> | Hixie: er, I realize I just confused the hidden attribute with input/@type=hidden |
| 07:41 | <Hixie> | ah ok |
| 07:42 | <MikeSmith> | Hixie: v.nu code currently doesn't try input/@type=hidden as labelable |
| 07:42 | <Hixie> | makes sense |
| 07:42 | <MikeSmith> | OK |
| 07:42 | <Hixie> | what with <input type=hidden> being hidden and all |
| 07:42 | <MikeSmith> | heh |
| 07:42 | <MikeSmith> | yeah |
| 07:42 | <Hixie> | not sure it's supported by the spec yet |
| 07:42 | <MikeSmith> | right |
| 07:42 | <Hixie> | but if it's not that's a spec bug imho |
| 07:43 | <MikeSmith> | OK |
| 07:43 | <MikeSmith> | I'll either raise it myself or ask the v.nu bug commenter to |
| 07:43 | <Hixie> | thanks |
| 07:48 | <Hixie> | i'd like to lodge a formal whine about the fact that the vertical text stuff in css isn't based on logical directions |
| 07:48 | <Hixie> | having to rewrite every algorithm for vertical text even though there's no difference except height becomes width, top becomes left, etc, is annoying. |
| 07:49 | <annevk> | there are proposals for introducing new properties for that |
| 07:49 | <annevk> | not sure if that was logical-height or something else... |
| 07:49 | <Hixie> | it's not the properties i mean, it's the actual model |
| 07:49 | <annevk> | but then vertical text is going nowhere fast and I'm not really complaining as it is darn complicated |
| 07:50 | <Hixie> | yeah teh lack of vertical text in css3 is the reason <canvas> doesn't have vertical text drawing methods |
| 07:50 | <Hixie> | it's all in the html spec, but commented out |
| 07:51 | <annevk> | ja |
| 07:51 | <annevk> | the most convincing vertical text example so far has been Japanese books for me |
| 07:52 | <annevk> | but layout engines for those do not have to be as complex as interactive layout engines for the Web yet we are probably going there anyway |
| 07:55 | <MikeSmith> | annevk: I think the market is going there without you |
| 07:55 | <MikeSmith> | or rather, going there whether we like it not |
| 07:56 | <MikeSmith> | e.g., iPad as book reader |
| 07:56 | <MikeSmith> | and I am sure there are going to be a lot of other such coming out |
| 07:57 | <MikeSmith> | that is, PCs that double as book readers |
| 07:57 | <annevk> | I said we are probably going there :) |
| 07:57 | <MikeSmith> | oh |
| 07:57 | <MikeSmith> | ah |
| 07:58 | <MikeSmith> | sorry... |
| 07:58 | <annevk> | no worries |
| 07:58 | <annevk> | but unless we are extremely careful performance, stability, etc. will all be impacted |
| 07:59 | <MikeSmith> | yeah, would seem so |
| 07:59 | <Peter`> | Quick question: someone posted a page here a few days ago (from Philip?) with lots of research-pages of popular websites, like how many used certain elements, css properties, validated, etcetera. Would anyone have that link for me? |
| 08:02 | <MikeSmith> | Peter-: you don't mean http://code.google.com/webstats/ ? |
| 08:03 | <Peter`> | No, it was a plain directory index, nothing fancy |
| 08:03 | <MikeSmith> | maybe Philip` own results from his dmoz data crunching |
| 08:05 | <Peter`> | http://philip.html5.org/data/ that one |
| 08:05 | <MikeSmith> | http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index |
| 08:05 | <MikeSmith> | ah |
| 08:07 | <annevk> | Peter`, so when is the proprietary pseudo-class and -element table coming out? ;) |
| 08:07 | <Peter`> | I doesn't have what I'm searching for though, so I'll rephrase my question: would you know of any research to the usage of css properties, specifically vendor-prefixes ones? |
| 08:08 | <Peter`> | annevk: and attributes! I found these too, lol |
| 08:08 | <Peter`> | annevk: hopefully later on this week, I got some lists, but I'd to group them together more clearly and create some test pages (and wait until all the retweets/stuff slows down a bit) |
| 08:11 | <annevk> | Peter`, http://devfiles.myopera.com/articles/599/cssproplist-url.htm |
| 08:11 | <annevk> | Peter`, via http://dev.opera.com/articles/view/mama-css-syntax/ |
| 08:11 | <annevk> | it seems Word is dominating the score |
| 08:12 | <Peter`> | Oh perfect, thank you! |
| 08:19 | <annevk> | Hixie, how does the media element's rendering area interact with user agent supplied controls? |
| 08:19 | <annevk> | Hixie, they should probably not overlap the captions |
| 08:20 | <Hixie> | they're transient anyway |
| 08:23 | <Peter`> | annevk: the css property list, is that public and do you know when it got published (December 2008?)? |
| 08:23 | <annevk> | how is it not public? |
| 08:24 | <Peter`> | not public as in "rather don't share" |
| 08:24 | <Peter`> | wouldn't know why, but just checking, I got that request more often |
| 08:26 | <annevk> | if I did not want to share it I would not have posted it to a public channel :) |
| 08:26 | <annevk> | it's also linked from that article |
| 08:27 | <Peter`> | ah, I see |
| 08:35 | <jgraham> | eseidel: The bugs 9580-9582 should cover your issue |
| 08:35 | <eseidel> | jgraham: I don't see how |
| 08:36 | <eseidel> | jgraham: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10140 |
| 08:36 | <eseidel> | jgraham: which is that a dupe of? |
| 08:37 | <annevk> | eseidel, there's http://wiki.whatwg.org/wiki/ParserIssues |
| 08:37 | <jgraham> | eseidel: I'm not sure, but those bugs encompass the only changes that html5lib has made to the spec |
| 08:37 | <jgraham> | in this area |
| 08:37 | <annevk> | eseidel, afaik that's all there's to know about issues with the HTML parser |
| 08:37 | <eseidel> | annevk: I'm using http://tinyurl.com/2c6p8uf |
| 08:37 | <jgraham> | And afaik we get out of foreignContent |
| 08:38 | <jgraham> | s/foreignContent/the secondary insertion mode/ |
| 08:38 | <eseidel> | jgraham: I believe you. :) I just need someone to explain to me how :) since I'm clearly not finding it in the spec |
| 08:39 | <jgraham> | eseidel: Without looking at the spec, I think what happens is that you typically process the token after the </svg> in foreign content mode and it gets processes as if in the secondary insertion mode and then you switch out of the secondary insertion mode |
| 08:40 | <annevk> | eseidel, kk |
| 08:40 | <jgraham> | Although that doesn't quite look like the problem you are having |
| 08:40 | <jgraham> | So... I'll check in a bit when I am not at home |
| 08:41 | <eseidel> | jgraham: k |
| 09:09 | <Hixie> | ok i've now done all of the websrt rendering stuff except the ::cue pseudo |
| 09:12 | <annevk> | pseudo should not be too hard? |
| 09:12 | <Hixie> | should be pretty easy |
| 09:14 | <Hixie> | oh and after that i'll comment out all the vertical text stuff |
| 09:16 | <Hixie> | ok bed time |
| 09:16 | <Hixie> | nn |
| 09:48 | <kennyluck> | Wow, MikeSmith, what makes you write the "Linked-Data Semantics" part? -> http://dev.w3.org/html5/markup/a.html#a-linked-data |
| 10:00 | <MikeSmith> | kennyluck: because I think its useful to point out that there are native elements in HTML that already have characteristics that make them particularly useful for expressing the kinds semantic associations that the "semantic web" is supposed to be all about, as far as I understand it |
| 10:01 | <MikeSmith> | and I think the semweb community does way to much hair-splitting about terms, when nobody else outside of the community cares about the fine points |
| 10:02 | <kennyluck> | Sure. |
| 10:02 | <MikeSmith> | I think you guys should be socializing the term "linked data" as much as you possibly can |
| 10:02 | <kennyluck> | But what I can tell, is that Linked Data is just about linking. |
| 10:03 | <kennyluck> | The principles that you should put links in your document, ideally linking to other domains. |
| 10:03 | <kennyluck> | This concept is a bit separated from machine-readible data/metadata, I think. |
| 10:03 | <MikeSmith> | the term "linked data" should be about whatever helps to get it the most attention, whatever helps to get the most awareness-raising done |
| 10:03 | <kennyluck> | Linked Data is actually a term targeting the Semantic Web community. |
| 10:04 | <kennyluck> | Those close their data and don't link to other datasets. |
| 10:04 | <kennyluck> | This is the historical origin of the term Linked Data, I believe. |
| 10:04 | <kennyluck> | But of course we can mix it with the "machine-readible" concept. |
| 10:04 | <MikeSmith> | I don't get the impression that most Web developers are terrifically fond of the term "semantic web" .. at least they are not fond of the connotations it has taken on |
| 10:05 | <MikeSmith> | kennyluck: yeah, agreed that the "machine-readible" characteristic is of course a key |
| 10:06 | <MikeSmith> | but it does not make for a particularly good section title in this particular context |
| 10:06 | <workmad3> | ah, semantic web |
| 10:06 | <kennyluck> | I am not sure. We never use the word "Linked Data Semantics", though. |
| 10:07 | <MikeSmith> | kennyluck: the entire Web is arguably just "linked data" |
| 10:07 | <workmad3> | indeed |
| 10:07 | <MikeSmith> | and even normal Web pages are obviously "machine readable" |
| 10:07 | <workmad3> | just not very machine friendly and missing a lot of meaning |
| 10:07 | <kennyluck> | It is, by the definition. |
| 10:07 | <workmad3> | (at least not machine-readable meaning) |
| 10:07 | <MikeSmith> | true |
| 10:08 | <MikeSmith> | so it gets back to "meaning" being key |
| 10:08 | kennyluck | is reading http://net.tutsplus.com/tutorials/html-css-techniques/html5-microdata-welcome-to-the-machine/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nettuts+%28NETTUTS%29 |
| 10:08 | <workmad3> | which obviously boils down to semantics :) |
| 10:08 | <MikeSmith> | bingo |
| 10:08 | <kennyluck> | In my mind, "machine-readibilty" is how much the underlining database is recoverable. |
| 10:09 | <MikeSmith> | hence, my section title, "Linked data semantics" |
| 10:09 | <workmad3> | kennyluck: something can be 'machine readable' without it being (for want of a better term) 'machine understandable' |
| 10:09 | <kennyluck> | Is there any good read from the Microdata community that explains "machine-readiblity" well? |
| 10:10 | <workmad3> | databases are a good example of this... you can store data in a database in whatever form you want |
| 10:10 | <workmad3> | machine can read it and spit it out at users... but if it had some knowledge of the meaning, it could start to do more interesting things |
| 10:10 | <workmad3> | which is pretty much the entire case for semantic web and linked data |
| 10:11 | <kennyluck> | Hmm.. |
| 10:11 | <workmad3> | the technical details for the popular technologies (rdf and triplestore) seem to have focussed on graphs though... just like so many other CS problems :) |
| 10:12 | <kennyluck> | I think what RDFa/Microdata tries to do is to expose the database with good control. |
| 10:13 | <kennyluck> | Not sure about the "if it had some knowledge of the meaning," argument. |
| 10:13 | <workmad3> | it tries to expose the data with extra data about the semantics |
| 10:13 | <MikeSmith> | workmad3: this is why I want to point out in this document that particular HTML elements have characteristics that naturally lend them to be useful for adding some knowledge of meaning |
| 10:13 | <kennyluck> | Not certainly. |
| 10:13 | <workmad3> | kennyluck: knowledge is a tricky one, admittedly |
| 10:13 | <kennyluck> | MikeSmith, what you are talking about sounds like "Metadata". |
| 10:14 | <workmad3> | kennyluck: bingo (or at least my understanding) |
| 10:14 | <kennyluck> | I feel like I like the "database recoverable" part of Linked Data/Semantic Web |
| 10:15 | <kennyluck> | Sometimes we just want Google to get the whole database so that it can do good data integration. |
| 10:15 | <workmad3> | and so they can sell it for advertising revenue... |
| 10:15 | <workmad3> | oh wait, that's what *google* wants |
| 10:15 | <MikeSmith> | kennyluck: it sounds to me like "linked data" in the non-pinhead/hair-splitting sense of the word |
| 10:16 | <workmad3> | semweb and linked data is built on splitting hairs in my (limited) experience |
| 10:16 | <kennyluck> | workmad3, We want good data integration. Good's revenue is of little interest to me. |
| 10:16 | <kennyluck> | s/Good/Google/ |
| 10:16 | <workmad3> | kennyluck: :) |
| 10:17 | <MikeSmith> | workmad3: that's the problem.. dudes have become like Pharisees having their own internal esoteric disputes about every little thing |
| 10:18 | <workmad3> | sounds about right |
| 10:19 | <workmad3> | and I'd better get back to working on this linked data project I've been moved onto :) |
| 10:27 | <kennyluck> | MikeSmith, if I were you I would write something like this. Section Title: Linked Data. Content: The use of <a> satisfies all the principles of Linked Data and utilizes the full power of Web. To make these links more machine-readable, you can use Microdata itemprop/RDFa rel, etc. |
| 10:28 | <kennyluck> | In the Semantic Web community we have this saying..."It's not Semantic what's new, it's the Web what's new". |
| 10:29 | <kennyluck> | And Linked Data is, as I said, a phrase to remind those RDF academic people being aware of the Web (putting RDF data on Web instead of local machine, make cross-domain links, etc.) |
| 10:29 | <MikeSmith> | kennyluck: this doc is not for the RDF academic people |
| 10:30 | <MikeSmith> | it's just a reference to try to give some details about particular characteristics of individual HTML elements |
| 10:31 | <MikeSmith> | I don't think there should necessarily be any defined set of "principles for Linked Data" |
| 10:31 | <kennyluck> | Yes, I know. I am just giving you the context on how the term(Linked Data) is born. It's not really for Web developers, I think. Web Developers know these principles well (put things on the Web, etc.) but the academics don't. |
| 10:31 | <MikeSmith> | it's like the term "HTML5" |
| 10:32 | <MikeSmith> | some people get upset about it being used to refer to CSS and SVG and other things that are not technically part of HTML5 at all |
| 10:32 | <kennyluck> | Ah, right. |
| 10:33 | <kennyluck> | Yeah, maybe Linked Data = things on the Web + machine-readibilty + etc. etc. would be also nice. |
| 10:33 | <MikeSmith> | there are really great sites like html5rocks.com and html5readiness.com that actually provide a lot of detail about CSS and other stuff in addition to HTML5 and APIs |
| 10:35 | <kennyluck> | I see. I am not that against your idea. I just wonder whether people in this channel like the idea of Microdata being associated with Linked-Data. |
| 10:36 | <Workshiva> | I don't think the people in this channel care so much about names |
| 10:36 | <MikeSmith> | linkeddatarocks.com |
| 10:37 | <MikeSmith> | linkedatareadiness.com |
| 10:37 | <kennyluck> | Sure, great, then. |
| 10:37 | <kennyluck> | :) |
| 10:37 | <Workshiva> | Does it work? Does it do something useful? Great |
| 10:38 | <kennyluck> | Yeah, agreed. Alright. You just tell me I should go back to work, Workshiva. :) |
| 10:40 | <Workshiva> | I seem to recall reading a blog where some linked data person wanted to disassociate linked data from rdf |
| 10:41 | <MikeSmith> | that would seem like a positive step |
| 10:43 | <kennyluck> | Probably. |
| 10:45 | <MikeSmith> | I think the community could really use some primer-level/core-concepts documents that don't explain everything strictly in terms of RDF |
| 10:46 | <MikeSmith> | I think stuff like http://www.w3.org/TR/rdf-primer/ and http://www.w3.org/TR/rdf-concepts/ are not useful to normal Web developers |
| 10:47 | <kennyluck> | The Microdata/Microformat/RDF community should collaboratively write a document explaining about machine-readibility using non-RDF terms, I think. |
| 10:47 | <MikeSmith> | kennyluck: yeah |
| 10:47 | <MikeSmith> | that would be a good thing |
| 10:47 | <MikeSmith> | get everybody remembering what the original problem was they they set out to solve to begin with |
| 10:48 | <kennyluck> | I like terms such as "database recoverabity" or maybe "lossless HTML output" |
| 10:48 | <boblet> | anything to explain this stuff in terms that don’t make my eyes glaze over in 5 seconds would be welcome |
| 10:49 | <phrearch> | hey |
| 10:49 | <phrearch> | how does cookie authentication work with websockets? |
| 10:50 | <boblet> | way too much energy goes to infighting — could be used so much more productively for education and compare/contrast |
| 10:50 | <boblet> | hey phrearch |
| 10:50 | <phrearch> | hi boblet |
| 10:51 | <phrearch> | from what i understand of the .76 specs, the cookie is set during handshake? |
| 10:51 | <boblet> | punt — MikeSmith? |
| 10:53 | <MikeSmith> | no idea |
| 10:53 | <MikeSmith> | phrearch: what part of the spec is not clear? |
| 10:54 | <phrearch> | MikeSmith: im not sure how the cookie is set |
| 10:55 | <phrearch> | i have an implementation of websockets in twisted like http://paste.pocoo.org/show/236897/ |
| 10:55 | <phrearch> | i dont think that one has cookie support yet |
| 10:56 | <phrearch> | and cant it use sessions instead? |
| 10:57 | <MikeSmith> | phrearch: I don't know |
| 10:57 | <MikeSmith> | but I suspect it's quite clear if you read the spec |
| 10:58 | <phrearch> | yea :) |
| 10:58 | <MikeSmith> | especially if you read it at http://www.whatwg.org/specs/web-apps/current-work/complete/network.html |
| 10:58 | <MikeSmith> | where it's in a more readable format |
| 11:01 | <phrearch> | aha cool |
| 11:02 | <MikeSmith> | phrearch: but you not supposed to know about that version of the spec |
| 11:02 | <MikeSmith> | so keep it a secret |
| 11:04 | <phrearch> | sure |
| 11:12 | <Matjas> | ←♥♡♥♡♥♡♥→ |
| 11:12 | <Matjas> | or, you know, →♥♡♥♡♥♡♥→ |
| 12:32 | <MikeSmith> | chrome team already implementing DeviceOrientation? |
| 12:32 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=39588 |
| 12:32 | <MikeSmith> | annevk: ↑ |
| 12:34 | <MikeSmith> | http://dev.w3.org/geo/api/spec-source-orientation.html |
| 12:35 | <annevk> | terminology of that draft is somewhat wrong |
| 12:35 | <MikeSmith> | Euler angles |
| 12:36 | <annevk> | well, I guess it works in a way |
| 12:36 | <MikeSmith> | the illustrations are helpful |
| 12:36 | <annevk> | I meant the event dispatching text |
| 12:36 | <annevk> | though that needs updating regardless to say something about .bubbles and .cancelable and all |
| 13:05 | <annevk> | MikeSmith, http://www.youtube.com/watch?v=kdFui74_jvY |
| 15:09 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=4357 - any application cache guys around? |
| 15:10 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=4358 microdata question |
| 17:08 | <boblet> | I’d like to check the commit logs of the WHATWG spec — http://html5.org/tools/web-apps-tracker making diffs seems overkill, is there anything like http://dev.w3.org/cvsweb/html5/ ? |
| 17:13 | <Workshiva> | boblet: The commit-watchers archives, maybe? |
| 17:14 | <boblet> | Workshiva: heh — that’s what I found actually. not the best, but oh well |
| 17:20 | <annevk> | boblet, you can give the home page of tracker a limit argument |
| 17:21 | <annevk> | boblet, if you set it to -1 you get everything ever recorded |
| 17:21 | <annevk> | boblet, running svn log http://svn.whatwg.org/webapps/source also works of course |
| 17:21 | <boblet> | annevk: woah. sounds like that’ll make the server elves work hard |
| 17:21 | <boblet> | annevk: oh you can remotely svn log on a repo you don’t have? nice |
| 17:22 | <boblet> | I’ll do that |
| 17:22 | <annevk> | (it takes a while for tracker, but it's not too bad) |
| 17:22 | <boblet> | annevk: I wouldn’t mind if it was just the logs, but the diff seems like it must be brutal :) |
| 17:23 | <annevk> | it's not computing diffs to show the homepage |
| 17:23 | <annevk> | it runs svn log for that |
| 17:24 | <boblet> | but think of the elves! |
| 18:03 | <boblet> | I just love forum software that emails you your password in the account created email, whereby love I mean hate |
| 18:03 | <boblet> | phpBB you suck |
| 18:03 | <annevk> | it's rather convenient I think |
| 18:04 | <annevk> | I always forget those passwords |
| 18:42 | <TabAtkins> | I just use a single password for all those unimportant things. Don't have to remember them specially then. |
| 18:52 | <annevk> | then i'd have to change them all if one gets compromised somehow |
| 18:54 | <jgraham> | Given they are being sent in plain text in email, they are all compromised (or at least might be) |
| 18:54 | <jgraham> | Also: http://blog.arcanedomain.com/2010/07/worldwide-celebration-of-dan-connollys-contributions-to-the-web/ |
| 19:01 | <TabAtkins> | annevk: I haven't had a password compromised in 10 years, as far as I know, so apparently I'm fine. |
| 19:14 | <oal> | How can I find the position of the caret inside of a contenteditable div? |
| 19:40 | <Hixie> | so what do i have to say to define a pseudo-element? |
| 19:41 | <Hixie> | is there a grammar or something I have to specify? |
| 19:42 | Hixie | looks at the selectors spec |
| 19:42 | <boblet> | annevk: that’s fine if you forgot and are requesting, but it’s just wrong to send a password unasked |
| 19:43 | <boblet> | although I use a tool to make individual passwords per domain so only my whatwg.org accounts could be compromised :) oh noes! |
| 19:44 | <boblet> | hey Hixie, can you give me more details about the microdata vcard vocab being based on vcard not “an out-of-date fork of hcard”? |
| 19:44 | <boblet> | or did I misunderstand? |
| 19:46 | <Hixie> | i just went down the vcard spec and mapped it directly to microdata |
| 19:46 | <Hixie> | i had originally made some minor changes to match hcard in places, but i've since removed those |
| 19:48 | <boblet> | Tantek’s take: “Avoid the "microdata vCard vocabulary" as in many ways it is an out-of-date fork/snapshot of hCard, even though portions of it appear to based directly on the vCard RFC. as well” |
| 19:48 | <boblet> | http://microformats.org/wiki/microdata#microdata_vCard_vocabulary |
| 19:48 | <Hixie> | tantek is welcome to his opinion :-) |
| 19:48 | <boblet> | Hixie: was that the fn magic? any other hcard -> vcard reversions? |
| 19:48 | <Hixie> | i think the only bit was the stuff with FN, yeah |
| 19:49 | <Hixie> | everything else is just a straight mapping of the vcard spec |
| 19:49 | <Hixie> | i did use the hcard names for the bits of vcard that needed splitting into multiple fields, but just to make sure the terminology was consistent, it's not "forked from hcard" or anything |
| 19:49 | <boblet> | yeah I’m kind of finding it strange that the whole thing about hcard is that it’s vcard, but this vocab is based on vcard so it’s completely different |
| 19:49 | <Hixie> | *shrug* |
| 19:50 | <boblet> | indeed |
| 19:50 | <boblet> | thanks for the info, will ping the µF list with it |
| 19:50 | <Hixie> | the whole point of microdata is that people can use whatever vocabularies they like; the vcard one is basically a proof of concept to show that it is possible to design a vocabulary in very little time and to show how to write a spec for one |
| 19:51 | <Hixie> | whether people use it or not is really up to them, i don't care so much |
| 19:51 | <boblet> | cool |
| 19:54 | <boblet> | it’s definitely a nice spec — I find the microformats specs to be a little hard to refer to. i normally use the pdf cheatsheet |
| 19:54 | <Hixie> | it's definitely a more precise spec |
| 19:54 | <Hixie> | the microformat specs always seem extremely vague to me |
| 19:54 | <Hixie> | not at all spec-like |
| 19:54 | <boblet> | well, maybe hcard 1.0.1 will clean things up :| |
| 19:55 | <boblet> | anyhow, thanks for your time |
| 19:55 | <annevk> | TabAtkins, yeah, me neither; not really an interesting target I suppose |
| 19:55 | <boblet> | nn all |
| 19:57 | <annevk> | Hixie, yeah, the grammar for the argument needs to be defined |
| 19:57 | <Hixie> | is there an example of this being done anywhere? |
| 19:57 | <annevk> | only poorly |
| 19:57 | <annevk> | for nth-child |
| 19:58 | <annevk> | but I think in your case it is easier since they can just be IDENT, no? |
| 19:58 | <Hixie> | probably |
| 19:59 | <annevk> | so you can do it in terms of the Selectors grammar and see who is annoyed |
| 20:00 | <annevk> | cue_argument : S* IDENT S* [ COMMA S* IDENT S* ] |
| 20:00 | <annevk> | ; |
| 20:00 | <annevk> | something like that |
| 20:00 | <Hixie> | k |
| 20:00 | <Hixie> | thanks |
| 20:01 | <AryehGregor> | oal, try looking at this. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#documentSelection (only partly implemented in any browser, so might not do what you want in practice) |
| 20:01 | <annevk> | Hixie, oh, you also have to say that COMMA is added to the expression production |
| 20:01 | <oal> | I'll try, AryehGregor. Thanks |
| 20:02 | <Hixie> | annevk: noted |
| 20:02 | <annevk> | Hixie, or maybe you should make it space-separated |
| 20:02 | <Hixie> | 21:06 < annevk> Hixie, oh, you also have to say that COMMA is added to the expression production |
| 20:02 | <Hixie> | er |
| 20:02 | Hixie | pasted into the wrong window! |
| 20:02 | <AryehGregor> | In theory, document.getSelection().anchorNode.anchorOffset might hypothetically do what you want, if it works. |
| 20:02 | <Hixie> | annevk: yeah that might be best |
| 20:03 | <Hixie> | annevk: or something like that |
| 20:10 | <TabAtkins> | Hixie: You don't have to do anything special to define a pseudoelement. Just define precisely where the element is created and under what conditions. |
| 20:10 | <TabAtkins> | Though, since the internal nodes correspond to real (unnamed) elements to CSS, I think a pseudoclass is the correct thing to use. |
| 20:12 | Workshiva | pokes TabAtkins some more |
| 20:12 | <Hixie> | wait, what? that makes no sense |
| 20:12 | <TabAtkins> | Workshiva: What? |
| 20:12 | <annevk> | Hixie, yeah, don't listen to TabAtkins |
| 20:13 | <TabAtkins> | Hixie: Pseudoelems create new elements in the element tree. Pseudoclasses select existing elements in the element tree, based on information that isn't available straight from the normal cascade. |
| 20:13 | <annevk> | TabAtkins, pseudo-elements don't create new elements |
| 20:13 | <TabAtkins> | annevk: Yes they do? |
| 20:13 | <annevk> | TabAtkins, they either create new boxes or refer to existing ones |
| 20:13 | <Workshiva> | TabAtkins: You're away on talk :) |
| 20:13 | <annevk> | to allow you to style them |
| 20:14 | <annevk> | which is exactly what is happening here |
| 20:14 | <TabAtkins> | No, pseudoelem creation happens at the element-tree level, not the box-tree level. |
| 20:14 | <TabAtkins> | That way, frex, anonymous table box creation happens appropriately when ::before is used, etc. |
| 20:15 | <annevk> | e.g. consider ::value |
| 20:16 | <annevk> | there's a box there regardless of whether you use the pseudo-element there or not |
| 20:16 | <annevk> | but the pseudo-element provides a way to style it |
| 20:16 | <annevk> | same thing with video::cue |
| 20:16 | <TabAtkins> | True, in that case. Pseudoelems can also act as aliases to otherwise-hidden boxes, sure. |
| 20:16 | <TabAtkins> | So, sure, video::cue is fine I guess. |
| 20:16 | <annevk> | I'm not really sure how else you would do it... |
| 20:17 | <annevk> | pseudo-class doesn't make sense |
| 20:17 | <zcorpan_> | video:cue would style the video element |
| 20:17 | <TabAtkins> | Right, you wouldnt' do video:cue. |
| 20:17 | <TabAtkins> | Assuming a selector that's already rooted in the embedded document, though, :cue() would then select any cue elements. |
| 20:18 | <annevk> | but there's no DOM |
| 20:18 | <TabAtkins> | Hixie's defined how the cue objects are translated into CSS-understandable terms, so you get something functionally equivalent to the DOM for CSS's purposes. |
| 20:19 | <annevk> | no, you get CSS boxes |
| 20:19 | <TabAtkins> | At least, you have a tree structure of elements. |
| 20:19 | <annevk> | of boxes :) |
| 20:22 | <Hixie> | you do technically have a DOM-like structure as well as boxes |
| 20:22 | <Hixie> | tab is right about that |
| 20:22 | <Hixie> | but i don't think it means it makes sense to have pseudo-classes |
| 20:22 | <Hixie> | just like we don't have pseudo-classes with XBL |
| 20:22 | <Hixie> | and those really are DOM elements |
| 20:23 | <Hixie> | to use psuedo-classes we'd have to apply the stylesheet to two documents -- the HTML one, and the WebSRT one |
| 20:23 | <Hixie> | and that would mean you couldn't style each <video> separately |
| 20:23 | <Hixie> | it would be very weird |
| 20:23 | <TabAtkins> | annevk: Section 12.3.2.1, subsection 8.11 |
| 20:23 | <annevk> | hmm, WebSRT as XBL binding? |
| 20:23 | <Hixie> | no no don't mix them! :-P |
| 20:24 | <Hixie> | don't cross the streams! |
| 20:24 | <TabAtkins> | Hixie: Yeah, I see that. And using pseudoelems as aliases into an opaque structure is already an established idiom, so that's fine. |
| 20:24 | <annevk> | XBL has ways to define pseudo-element matching |
| 20:25 | <jgraham> | If you define the whole thing in terms of XBL, we can pretend that you have to implement XBL to have captions |
| 20:26 | <jgraham> | So get XBL work way up priority lists |
| 20:26 | <jgraham> | </evilPlan> |
| 20:26 | <annevk> | great plan, I say |
| 20:26 | <jgraham> | I was thinking more <evilPlan class="stupid doomed"> |
| 20:28 | <annevk> | would allow for implementing this feature prolly almost entirely in terms of other features |
| 20:28 | <annevk> | not sure if that performs well or anything |
| 20:29 | TabAtkins | sighs, and notes once again that he really needs to hunker down and define the CSS element-tree and box-tree so we can actually do extensions sanely. |
| 20:31 | jgraham | often gets the no-doubt-selection-biased impression that TabAtkins has volunteered to do almost all the heavy lifting in CSS |
| 20:31 | <TabAtkins> | Man, no one else is doing it. |
| 20:31 | <Hixie> | i know the feeling |
| 20:31 | <TabAtkins> | As soon as I get this testing thing off my back, it's hardcore CSS all the way. |
| 20:31 | <jgraham> | I was hoping that it was just that other CSS people didn't hang out here |
| 20:32 | <Workshiva> | This is wack |
| 20:32 | Hixie | tries to work out how to phrase the prose that says that ::cue only matches cues for the media element on which the ::cue was specified |
| 20:32 | <TabAtkins> | To be fair, fantasai also does a lot of heavy lifting, just in the upper areas rather than the undercarriage. |
| 20:32 | <Workshiva> | In some situations, Chrome instantly loads a script from document.write before even finishing the current script block |
| 20:33 | <Workshiva> | I'm not very versed in the workings of document.write, does anyone know if this is remotely legal? |
| 20:34 | <jgraham> | Hixie: BTW do you happen to have seen http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency ? I need to dig into HTML5 and work out what is "supposed" to happen here but maybe you already know... |
| 20:37 | <Hixie> | looks like chrome and firefox are right |
| 20:37 | <Hixie> | but i'd have to see the exact code to be sure |
| 20:37 | <Hixie> | the html spec just enforces the security policy at very specific points -- e.g. when accessing the members of Window or Document |
| 20:38 | <jgraham> | Yeah |
| 20:38 | <Hixie> | so if you already have an Element, you don't have a problem |
| 20:38 | <jgraham> | (there is a testcase on the page if you care to look) |
| 20:39 | <Hixie> | yeah, opera is wrong here |
| 20:39 | <Hixie> | per html spec anyway |
| 20:40 | <Hixie> | also can i just say |
| 20:40 | <Hixie> | woohoo! |
| 20:40 | <Hixie> | the html spec is compatible with the web in this extremely obscure edge case! |
| 20:40 | <jgraham> | OK, I will report back and see if we are happy to change or if we want to duke it out with the others |
| 20:41 | <Hixie> | good luck trying to convince people to break ebay |
| 20:41 | <Hixie> | also it's not clear that there's any improved security to doing it opera's way here |
| 20:41 | <jgraham> | Well we would need to get the OTW people on ebay first |
| 20:41 | <jgraham> | Obviously |
| 20:42 | <jgraham> | But I am happy for us to change if there is no security risk |
| 20:42 | <jgraham> | I just need to convince the people who actually make the changes |
| 20:42 | <Hixie> | :-) |
| 20:42 | <jgraham> | s/changes/decisions/ |
| 20:42 | <Hixie> | those really should be the same people |
| 20:43 | <zcorpan_> | Hixie: why? |
| 20:44 | <Hixie> | because otherwise you end up with the people making the decisions not being the people with the intimate knowledge to make the decisions |
| 20:44 | <zcorpan_> | Hixie: the person with the best knowledge might be QA |
| 20:44 | <jgraham> | Hixie: That doesn't seem to be the way it works in general though (although in this specific case, in the specific case of Opera, it probably would be) |
| 20:45 | <Hixie> | zcorpan_: fair eough |
| 20:45 | <Hixie> | enough |
| 20:48 | <annevk> | shouldn't ::cue just match all media elements? |
| 20:49 | <Hixie> | it should surely not match any media elements |
| 20:50 | <annevk> | I mean all cues for all media elements within the document |
| 20:50 | <Hixie> | sure |
| 20:50 | <Hixie> | as opposed to what? |
| 20:50 | <annevk> | maybe I misunderstood when you said "tries to work out how to phrase the prose that says that ::cue only matches cues for the media element on which the ::cue was specified" |
| 20:52 | <TabAtkins> | annevk: He means like, if you say #myvideo::cue(), it should only match cues for <video id=myvideo>, not <video id=randomvid> elsewhere on the page. |
| 20:52 | <KrocCamen> | *::cue |
| 20:53 | <TabAtkins> | That would match the cues from all media elements on the page. |
| 20:53 | <Hixie> | annevk: i meant how to say that input::cue shouldn't do anything |
| 20:53 | <annevk> | hmm, I guess Selectors doesn't handle that automagically |
| 20:53 | <Hixie> | but ::cue should affect media elements, and foo > ::cue should affect children of foo, etc |
| 20:53 | <Hixie> | i ended up writing: |
| 20:53 | <Hixie> | <p>Pseudo-elements apply to elements that are matched by |
| 20:53 | <Hixie> | selectors. For the purpose of this section, that element is the |
| 20:53 | <Hixie> | <i>matched element</i>. The '::cue' pseudo-element affects the |
| 20:53 | <Hixie> | styling of parts of <span title="timed track cue">timed track |
| 20:54 | <Hixie> | cues</span> that are being rendered for the <i>matched |
| 20:54 | <Hixie> | element</i>.</p> |
| 20:55 | <Hixie> | what properties should i say apply to ::cue? |
| 20:55 | <TabAtkins> | Rather, I'd prefer you just say what properties *shouldn't* apply to cue. |
| 20:55 | <TabAtkins> | Cues are forced-inline, right? |
| 20:55 | <Hixie> | not sure what that means |
| 20:55 | <TabAtkins> | A cue element is supposed to be inline always? |
| 20:56 | <Hixie> | "cue element"? |
| 20:56 | <Hixie> | <ruby> is ruby-base |
| 20:56 | <Hixie> | <rt> is ruby-text |
| 20:56 | <Hixie> | etc |
| 20:56 | <annevk> | 'display' should probably not apply |
| 20:56 | <TabAtkins> | The nameless element that is generated for cues for the purpose of CSS. |
| 20:56 | <TabAtkins> | Yeah, I was trying to build up to saying that display shouldn't apply. |
| 20:56 | <Hixie> | there's also a positioned box and an anonymous inline and an anonymous ruby-something-else |
| 20:56 | <annevk> | and 'position' and 'float' I guess |
| 20:56 | <Hixie> | lots of stuff shouldn't apply |
| 20:57 | <Hixie> | margin-left, e.g. |
| 20:57 | <annevk> | what's wrong with margin? |
| 20:57 | <Hixie> | text-indent |
| 20:57 | <KrocCamen> | Would ::cue::outside be cheating? :P |
| 20:57 | <Hixie> | all kinds of stuff |
| 20:57 | <TabAtkins> | What's wrong with text-indent? |
| 20:57 | <Hixie> | text-indent inherits so it would screw everything up if you used it higher up the hierarchy, to start with |
| 20:57 | <TabAtkins> | KrocCamen: I suspect that should count as "not defined". Also illegal right now. |
| 20:58 | <Hixie> | (second text-indent doesn't apply to inlines, of which most of these boxes are) |
| 20:58 | <TabAtkins> | Then why worry about disallowing it? |
| 20:58 | <Hixie> | because the root box is block-leel |
| 20:58 | <Hixie> | level |
| 20:58 | <TabAtkins> | Yes, and it should be fine to indent the root box, shouldn't it? |
| 20:59 | <zcorpan_> | Hixie: shouldn't you just be able to select the background box, not the root box? |
| 20:59 | <Hixie> | TabAtkins: maybe |
| 20:59 | <Hixie> | zcorpan_: well you have to select the root box for setting 'font' |
| 20:59 | <zcorpan_> | Hixie: why? |
| 20:59 | <Hixie> | but i have some magic in place to move the background to the background box |
| 20:59 | <Hixie> | zcorpan_: otherwise you can't change the line height |
| 21:00 | <zcorpan_> | ok |
| 21:00 | <TabAtkins> | Hixie: Only worry about disallowing the things that you know will cause concrete problems. |
| 21:00 | <annevk> | maybe forbid a few of the obvious ones and add a comment that experimenting is welcome here |
| 21:00 | <TabAtkins> | Like, frex, setting display on a cue. |
| 21:00 | <annevk> | though I guess we want to avoid another ::first-line / ::first-letter disaster |
| 21:00 | <Hixie> | TabAtkins: that means i have to keep adding to the list as we add new things, and if i don't add it to the list for a week, we can end up with things being implemented that make no sense |
| 21:01 | <Hixie> | TabAtkins: whereas a whitelist is always fine |
| 21:01 | <TabAtkins> | Hixie: I highly doubt there are many things where it matters. The blacklist should be very small, and effectively static. |
| 21:02 | <TabAtkins> | annevk: ::first-letter isnt' a problem in terms of properties (though what precisely is wrapped in it is a different story...). ::first-line causes issues, but nothing that should be relevant for cues. |
| 21:03 | <annevk> | ::first-letter has exactly the same problems ::first-line has |
| 21:03 | <TabAtkins> | What do you mean? |
| 21:03 | <annevk> | consider e.g. <p><span>"</span>A... |
| 21:04 | <annevk> | well, <p>"<span>Atom</span> might be a better example |
| 21:04 | <TabAtkins> | What's the problem with ::first-letter there? |
| 21:04 | <annevk> | it matches "A |
| 21:04 | <annevk> | now float the span or something |
| 21:04 | <TabAtkins> | Ah, yes. I alluded to that. I'm talking about which *properties* are acceptable. |
| 21:04 | <KrocCamen> | It varies between browsers. Some include punctuation, others don’t. |
| 21:05 | <TabAtkins> | The fact that ::first-line and ::first-letter can easily create a misnested tree is a big problem, but a separate one. |
| 21:05 | <annevk> | TabAtkins, I think the latest is actually which properties apply innermost and which apply outermost, or something weirdly complicated like that |
| 21:05 | <annevk> | we should have just dropped them |
| 21:06 | <Hixie> | just from CSS2.1 i have to exclude at least these (and that doesn't include those that are excluded simply because they can't apply, like list-style-*): |
| 21:06 | <Hixie> | display, float, position, top, left, right, bottom, width, height, margin-top, margin-bottom, margin-left, margin-right, clip, clear, content, cursor, |
| 21:06 | <Hixie> | direction, max-height, min-height, max-width, min-width, orphans, overflow, page-break-*, text-align, unicode-bidi, widows, z-index |
| 21:06 | <TabAtkins> | The innermost/outermost debate is a result of no one knowing what the hell the element-tree is supposed to look like. Define the properly and we're fine. |
| 21:06 | <Hixie> | i'm not sure that's shorter than the list of those i need to enable |
| 21:06 | <Hixie> | lunch, bbiab |
| 21:06 | <annevk> | top/left/right/bottom cannot do anything if position does not apply |
| 21:06 | <TabAtkins> | Hixie: I don't understand why most of those have to be excluded. They may not *do* anything on a cue, but that doesn't mean they should be explicitly blacklisted. |
| 21:08 | <TabAtkins> | annevk: Of course, the question of *how* to properly define them is open. But it's possible, if someone would just sit down and do the work, and then all the retarded debate evaporates immediately. |
| 21:09 | <annevk> | oh god http://www.w3.org/TR/2005/REC-charmod-20050215/#C048 |
| 21:09 | annevk | wonders who came up with that |
| 21:10 | <jgraham> | Doesn't everyone do that anyway? |
| 21:10 | <TabAtkins> | That's... stupid. |
| 21:10 | <AryehGregor> | jgraham, no? |
| 21:10 | <annevk> | TabAtkins, it's possible, but the amount of implementation time and specification time does not outweigh the usefulness of these features (imo) |
| 21:10 | <TabAtkins> | I do it in hex, but there's no reason to encode that as a SHOULD. |
| 21:10 | <TabAtkins> | annevk: I agree. ^_^ |
| 21:10 | <zcorpan_> | "when there are both"? |
| 21:10 | <annevk> | TabAtkins, again imo, too much time has been wasted already |
| 21:10 | <jgraham> | Yeah, it is stupid to put it in a document |
| 21:11 | <jgraham> | let alone brandish RFC2119 |
| 21:11 | <annevk> | via http://www.w3.org/International/reviews/1007-polyglot/ |
| 21:38 | <annevk> | hmm, there's no security check at all for window.opener? |
| 21:50 | <eseidel> | I wonder what prompted HTML5 to cause "<head></head>\n<body>" to insert a text node between head and body |
| 21:50 | <eseidel> | old FF and old WebKit don't |
| 21:50 | <eseidel> | I haven't tested IE |
| 21:51 | <eseidel> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Chead%3E%3C/head%3E%0A%3Cbody%3E shows the change |
| 21:51 | <eseidel> | although it seems the live dom viewer does not work in IE |
| 21:53 | <jgraham> | It ought to I think |
| 21:54 | <annevk> | eseidel, I think except where it matters for compatibility the idea was to match the source tree as closely as possible |
| 21:55 | <jgraham> | Also, I think I agree about the <!doctype html><svg><foreignObject><p><table></table></foreignObject></svg> issue |
| 21:55 | <jgraham> | although html5lib does something slightly strange |
| 21:55 | <jgraham> | And I am not sure I read the spec right |
| 21:56 | <jgraham> | But it seems that </foreignObject> should close everything up to the matching <foreignObject> |
| 21:56 | <jgraham> | but does not |
| 21:59 | <jgraham> | (because foreignObject is in the scoping category so doesn't close other elements in step 3 of the "any other end tag" pattern in "in body" mode |
| 21:59 | <zcorpan_> | http://twitter.com/xmemphisx/statuses/18465424871 |
| 22:00 | <zcorpan_> | i wonder what's noisy about rdfa. the namespace declarations? |
| 22:01 | <annevk> | you can reply |
| 22:01 | <zcorpan_> | true |
| 22:03 | <jgraham> | The curies too I guess |
| 22:10 | <Hixie> | annevk: 'position' is 'absolute' on the cue |
| 22:11 | <Hixie> | TabAtkins: for each one, there is some reason why it messes with the rendering |
| 22:11 | <Hixie> | TabAtkins: in ways that would be unintuitive to say the least, and might even cause crashes or hangs if implemented exactly as specced |
| 22:12 | <TabAtkins> | Hixie: orphans, for example? |
| 22:15 | <annevk> | Hixie,ah |
| 22:16 | <Hixie> | TabAtkins: i couldn't work out how to define widows and orphans being handled in this case given that full-screen is paged and yet we don't want cues being affected by inherited widows and oprhans settings |
| 22:17 | <TabAtkins> | Full-screen is paged? |
| 22:17 | <Hixie> | in opera, at least |
| 22:18 | <TabAtkins> | My brain doesn't know how to respond to that. |
| 22:18 | <Hixie> | anyway i'm pretty convinced that i don't want to be using a black-list |
| 22:18 | <Hixie> | based on the above list |
| 22:18 | <Hixie> | none of the other pseudos use a black-list, as far as i can tell |
| 22:18 | <Hixie> | they all use a whitelist |
| 22:19 | <TabAtkins> | I don't know why I was misremembering them as blacklisting. Carry on then. |
| 22:23 | zcorpan_ | points eseidel to http://software.hixie.ch/utilities/js/live-dom-viewer/saved/544 |
| 22:24 | <eseidel> | zcorpan_: what about it? |
| 22:24 | <zcorpan_> | eseidel: it's different from what pre-html5 browsers do |
| 22:24 | <eseidel> | zcorpan_: ok, file a bug :) |
| 22:24 | <eseidel> | zcorpan_: I'm not sure why youe' pointing to me |
| 22:25 | <eseidel> | zcorpan_: I am implementing WebKit's HTML5 parser, I don't work on the spec |
| 22:26 | <zcorpan_> | eseidel: i know. i was looking at http://www.w3.org/Bugs/Public/show_bug.cgi?id=10157 but i see now that abarth filed that |
| 22:26 | <zcorpan_> | eseidel: i complained about this a few years ago but didn't manage to convince hixie |
| 22:26 | <zcorpan_> | i guess i should file a bug |
| 22:27 | <jgraham> | eseidel: If you are complaining here you work on the spec :) |
| 22:32 | <Hixie> | i think instead of ::cue and ::cue(voice) and ::cue(voice, part) i'm just going to have ::cue and ::cue-part(list...) where 'list...' is a list of identifiers or integers |
| 22:32 | <Hixie> | so you can have ::cue-part(narrator i) to match the italics part of a cue whose voice is the narrator |
| 22:33 | <TabAtkins> | ::cue(b i)? |
| 22:33 | <Hixie> | or ::cue-part(0 b before) to match <b> parts that are before the playback position and use voice 0 |
| 22:33 | <TabAtkins> | Also, can voices have arbitrary names? |
| 22:33 | <Hixie> | ::cue-part(b i) would match nothing |
| 22:34 | <Hixie> | no, the names are integers or the short list in the spec |
| 22:34 | <TabAtkins> | Ok. |
| 22:34 | <TabAtkins> | You can't have bold italic cues? |
| 22:34 | <TabAtkins> | bold italic *ruby* cues? |
| 22:35 | <zcorpan_> | TabAtkins: you can but they would be nested |
| 22:35 | <TabAtkins> | Is it possible to select that? |
| 22:35 | <zcorpan_> | TabAtkins: i mean the boxes, it wouldn't make sense to make the pseudo-element apply to all at once |
| 22:35 | <Hixie> | TabAtkins: you can but it's not possible to select them separately from all italics cues |
| 22:36 | <TabAtkins> | ;_; |
| 22:40 | <TabAtkins> | So it's ::cue-part( [ <voice> || <part> || <position> ] )? |
| 22:42 | <Hixie> | essentially |
| 22:43 | <Hixie> | maybe i should specify it that way explicitly in fact |
| 22:43 | TabAtkins | likes grammars. |
| 22:44 | <Hixie> | the question is what should happen if you say ::cue-part(bogus) |
| 22:44 | <Hixie> | should it be in the CSSOM or not? |
| 22:44 | <Hixie> | and if you say ::cue-part(b z) should it match the same as ::cue-part(b) or be ignored for matching? |
| 22:44 | <TabAtkins> | Nah, invalid declaration, thrown out. |
| 22:45 | <Hixie> | and should ::cue-part(b b) match anything? |
| 22:45 | <TabAtkins> | If you can only specify a single <part>, then specifying the same <part> twice violates the grammar. Invalid selector, thrown out. |
| 22:45 | <Hixie> | ok then i have to change what i've written so far |
| 22:45 | Hixie | does so |
| 22:48 | <Hixie> | any better keywords than "before" and "after" for denoting parts that are before or after the current playback position? |
| 22:48 | <TabAtkins> | "past" "future" |
| 22:48 | <zcorpan_> | Hixie: are they intended for karaoke? |
| 22:48 | <Hixie> | ooh, good |
| 22:48 | <Hixie> | thanks |
| 22:48 | <Hixie> | zcorpan_: yes |
| 22:49 | <Philip`> | earlier/later? |
| 22:49 | <jgraham> | Hixie: http://sloth.whyi.org/~jl/cross-domain.html was pointed out as a possible problem with the non-Opera cross domain stuff. Two documents changing their domains in such a way that two documents that did not change their domains can communicate |
| 22:50 | jgraham | is not confident enough of his understanding of all the security details here to be a good proxy |
| 22:51 | Hixie | looks |
| 22:52 | <Hixie> | why is that a problem? |
| 22:52 | <jgraham> | Well it is unexpected I think |
| 22:52 | <Hixie> | by whom? |
| 22:53 | <Hixie> | it seems normal to me... |
| 22:53 | <jgraham> | By (one of the) documents that is being accessed by a document on a different domain without having changed its document.domain to permit it |
| 22:53 | <jgraham> | I guess |
| 22:54 | <jgraham> | (I am told that the demo could be made to work in Opera too with a little more effort and cooperation) |
| 22:54 | <gsnedders> | jgraham: Stop working. |
| 22:54 | <gsnedders> | jgraham: It's almost midnight. |
| 22:54 | <gsnedders> | Sorry, I feel it's my duty to remind you of these things. |
| 22:54 | <jgraham> | gsnedders: No, it is midnight |
| 22:55 | <gsnedders> | It wasn't when I sent it. |
| 22:55 | <zcorpan_> | yes it was |
| 22:56 | <jgraham> | Hixie: the proposed solution, if one is needed, would be to make document.domain readonly after making a cross-origin access |
| 22:56 | <gsnedders> | My IRC client, with the time from pool.ntp.org thinks it was 23:59 damnit |
| 22:56 | <jgraham> | I have no opinion on whether that is sensible or web compatible |
| 22:56 | <jgraham> | or needed |
| 22:57 | <Hixie> | jgraham: well unless there's an actual vulnerability or compatibility issue here, i'd rather not change the web's security model |
| 22:58 | <jgraham> | Yeah I don't know. Maybe I will post to the list tommorrow and hope that some evil people have an opinion on whether it is harmless |
| 22:58 | <jgraham> | I mean other evil people |
| 22:59 | <jgraham> | I don't mean to understate your evilness |
| 22:59 | <annevk> | fwiw, I would prefer it if arguments to ::cue() behaved like type selectors and were not thrown out |
| 22:59 | <jgraham> | gsnedders: But you do have a point |
| 23:00 | <Hixie> | annevk: thrown out of the CSSOM or ignored for rendering? |
| 23:00 | <annevk> | that way if we add <mark> or whatever in the future you can use it in a comma-separated list without older clients barfing |
| 23:00 | <Hixie> | annevk: the comma would cause older clients to barf, not the new tag :-) |
| 23:00 | gsnedders | follows his own point and goes to sleep |
| 23:00 | <annevk> | ::cue(i), ::cue(future-element) { } |
| 23:00 | <jgraham> | It is a bit late to be doing anything not involving sleep |
| 23:00 | <gsnedders> | (not that I was working) |
| 23:00 | <TabAtkins> | annevk: The whole point of throwing things out is for older clients to not screw things up. |
| 23:00 | <Hixie> | annevk: oh i see |
| 23:01 | <annevk> | TabAtkins, we don't ignore i, future-element either |
| 23:01 | <Hixie> | annevk: so allow any keywords just make it not match if there are unknown keywords? |
| 23:01 | <annevk> | yeah |
| 23:01 | <annevk> | seems more consistent |
| 23:01 | <Hixie> | annevk: we do ignore :first-child, :fifth-child { } |
| 23:02 | <TabAtkins> | annevk: Ah, I see what you mean. |
| 23:02 | <annevk> | Hixie, not sure if that was a good idea or not |
| 23:03 | <TabAtkins> | annevk: Yeah, thinking about it a bit, doing "accept but dont' match anything" in selectors is the right behavior. |
| 23:07 | <annevk> | I'm not really sure why the ::first-child, ::unknown-child thing makes sense; I helped get it implemented in browsers, but I have no idea why it makes sense... I guess because the names are part of the syntax somehow... |
| 23:08 | <TabAtkins> | Yeah, it's silly. |
| 23:08 | <TabAtkins> | Think we could change it at this point? |
| 23:09 | <annevk> | I'm not sure if it's worth the hassle |
| 23:09 | <annevk> | but at least we can avoid it with idents specified within ::cue |
| 23:11 | <zcorpan_> | we can't change it, people use it to as a css filter these days |
| 23:11 | <annevk> | (Of course everything can be changed. In this case likely glazou and Bert will complain. Implementors will not be too happy with changes. QA will not be happy with changes. 0.0001% of the authors might care. Net benefit is that the language is somewhat saner, but mwah, who cares?) |
| 23:11 | <zcorpan_> | or at least with attribute selectors |
| 23:12 | <TabAtkins> | Holy crap authors-that-aren't-me are stupid. |
| 23:13 | <Hixie> | ok i'm done with the first draft of the timed track stuff |
| 23:13 | <Hixie> | you may now begin flaming me |
| 23:14 | <Hixie> | (i haven't yet added all the properties to the whitelists that need adding) |
| 23:14 | <Hixie> | (like border, padding) |
| 23:14 | <annevk> | someone was in here a couple of days ago arguing that we could not do WebSRT based on CSS because it didn't have text-outline |
| 23:15 | <TabAtkins> | That was assuming that we didn't do a background on the cue box. |
| 23:15 | <TabAtkins> | (Which we are, given the default CSS.) |
| 23:15 | <TabAtkins> | And even then, "color: white; text-shadow: 0px 0px 2px black;" works fine. |
| 23:15 | <zcorpan_> | text-outline seems nicer than background |
| 23:16 | <annevk> | Hixie, s/Italics Objects/Italic Objects/ ? |
| 23:16 | <TabAtkins> | Or, wait, I actually use 4 shadows on the text I'm looking at. |
| 23:17 | <Hixie> | annevk: ta |
| 23:17 | <TabAtkins> | 1 1, 1 -1, -1 -1, -1 1. |
| 23:17 | <Hixie> | annevk: (i'm still going through fixing minor issues like that) |
| 23:17 | <annevk> | Hixie, it seems you miss a bunch of closing spans as well for timed track cue voice identifier |
| 23:17 | <annevk> | k |
| 23:17 | <Hixie> | yeah i'm going through validator and xref bugs now |
| 23:18 | <Hixie> | ok i'm gonna take a break and send an e-mail about <device> |
| 23:19 | <Hixie> | i'll pause on the captions stuff for now, then get back to it in a bit after the websockets stuff and whatever else i have queued up |
| 23:19 | <Hixie> | parser bugs |
| 23:19 | <annevk> | I'm gonna read all that tomorrow :) good day |
| 23:19 | <annevk> | nn |
| 23:19 | <Hixie> | web apps cr |
| 23:19 | <Hixie> | etc |
| 23:19 | <Hixie> | nn |
| 23:20 | <zcorpan_> | yay websockets |
| 23:21 | <Hixie> | oh and change proposals |
| 23:21 | <Hixie> | i guess web sockets is next week |
| 23:22 | <Hixie> | bbiab |
| 23:37 | <TabAtkins> | Urgh. Every API from now until forever should treat collections of a single objects being equivalent to the object itself, and operations if an operation is done to a collection that's only valid on the objects in the collection, map the operation over the collection. |
| 23:37 | <AryehGregor> | That sounds like it will break horribly in some cases. |
| 23:38 | <TabAtkins> | Then you're doing things wrong. |
| 23:38 | <AryehGregor> | Like, if your single object is itself a collection, everything will get extremely confused. |
| 23:38 | <AryehGregor> | It doesn't work for anything that needs to sometimes operate on single objects and sometimes on collections. |
| 23:38 | <TabAtkins> | Arbitrary nesting is excused from this requirement. |
| 23:38 | <TabAtkins> | But when you can tell the difference between an object and a collection, then it should work as described. |
| 23:39 | <AryehGregor> | Also, it often doesn't really make sense. If you do len(0) in Python, should it really return 1 instead of throwing an exception because you're doing something stupid? |
| 23:39 | <AryehGregor> | That kind of behavior masks bugs. |
| 23:39 | <TabAtkins> | ?_? I don't see how len(0) is a relevant example. |
| 23:40 | <AryehGregor> | According to you, it should be treated like len([0]) and return 1. |
| 23:40 | <TabAtkins> | No, you have it wrong way round. |
| 23:40 | <TabAtkins> | And, still, arrays can be arbitrarily nested, and so are exempt from this. |
| 23:41 | <TabAtkins> | But, frex, in Django, Test.objects.all().id should return a list of ids of all the objects. |
| 23:42 | <TabAtkins> | (Rather than me having to explicitly map over the return value with [test.id for test in Test.objects.all()] |
| 23:42 | <AryehGregor> | Oh, I thought you were going both ways. |
| 23:43 | <AryehGregor> | Then your proposal superficially seems less objectionable. |
| 23:43 | <AryehGregor> | This could be coded in at a language level, in principle. |
| 23:43 | <TabAtkins> | Hmm, only insofar as something has a priviledged container type. Then you can treat a single object equivalently to a container containing that single object. |
| 23:44 | <TabAtkins> | But otherwise you can only auto-go from single-element container to the element itself, not in reverse. |
| 23:44 | <AryehGregor> | But you just said that's the only direction you want to go in. |
| 23:44 | TabAtkins | supposes this relies largely on privileged container types all the way through, actually. |
| 23:44 | <AryehGregor> | All you need is some notion of a container, there doesn't have to be only one. |
| 23:45 | <AryehGregor> | C++ and Python have the notion of a general container, that's enough. |
| 23:45 | <TabAtkins> | Not quite, because general containers can be objecs in and of themselves. |
| 23:45 | <AryehGregor> | So? |
| 23:46 | <TabAtkins> | So magicking them in this manner can cause problems. |
| 23:46 | <AryehGregor> | So in Python, if you access foo.bar, and foo does not have a property named bar, but it's a container of class Foo and all of its contents do, then return Foo(x.bar for x in foo). |
| 23:46 | <AryehGregor> | Recursively. |
| 23:46 | AryehGregor | just got scared at that last word. |
| 23:46 | <TabAtkins> | But when you have, say, Nodes and NodeLists, then it's fine to do Nodelist.foo when .foo is only defined for Nodes. |
| 23:48 | <TabAtkins> | Or foo(NodeList), if foo() normally only takes a single Node and NodeList contains only a single Node. |
| 23:49 | <AryehGregor> | If NodeList doesn't contain only a single Node, that should become (foo(x) for x in list) or something. |
| 23:49 | <AryehGregor> | This is inconsistent, though. |
| 23:49 | <AryehGregor> | I think the "always treat it as mapping the contents to a tuple" is probably more consistent. |
| 23:49 | <TabAtkins> | No it's not. There's a difference between a function and a method. |
| 23:50 | <AryehGregor> | I don't see why there should be in this case. |
| 23:50 | <TabAtkins> | Methods would be mapped. Functions would auto-unwrap. |
| 23:50 | <AryehGregor> | Why? |
| 23:50 | <TabAtkins> | Because it's convenient? |
| 23:50 | <AryehGregor> | It's inconsistent. |
| 23:51 | <TabAtkins> | Only because you're insisting that methods and functions must be treated the same. |
| 23:53 | <AryehGregor> | Because they are logically very similar. |
| 23:53 | <TabAtkins> | But not identical in most languages, and so a distinction between them can be made without being inconsistent. |
| 23:54 | <AryehGregor> | Making an artificial distinction between two very similar things is inconsistent. |
| 23:54 | <TabAtkins> | No, distinguishing between two *identical* things is. |
| 23:54 | <TabAtkins> | "Very similar" admits a distinction by definition. |
| 23:54 | <AryehGregor> | By that logic, there's no such thing as inconsistency, because as soon as you distinguish two things, they're different. |
| 23:55 | <AryehGregor> | Also, by the way, this scheme will completely blow up in so many cases. |
| 23:55 | <TabAtkins> | It works for jQuery. |
| 23:55 | <AryehGregor> | Like if the container actually contains an unlimited amount of stuff. |
| 23:55 | <AryehGregor> | It has to be selectively opted into, though, not imposed at the language level. |
| 23:55 | <TabAtkins> | If you have an infinite container, you ahve lazy maps to start with. |
| 23:55 | <AryehGregor> | Maybe it could have opt-in allowed at the language level, to make it easier. |
| 23:55 | <AryehGregor> | Probably excessive. |
| 23:56 | <TabAtkins> | All I know is, there is absolutely no need to distinguish between whether $("p") matches one or multiple results in jQuery. There are many other APIs I've run into where a similar facility would be useful. |