| 00:00 | <zcorpan> | Lachy: if you figure out how it should work, archive notes so that it can be specced in web dom core |
| 00:03 | <zcorpan> | why is http://html5.org/tools/web-workers-tracker empty? |
| 00:03 | <Lachy> | I wasn't planning on reverse engineering it. Was just curious as it was mentioned on public-webapps as a way to sort nodes in an array |
| 00:03 | <Lachy> | and I never knew the method existed before |
| 00:04 | <Hixie> | zcorpan: i may have broken it when i migrated everything to html5's source document |
| 00:04 | <Hixie> | though i thought i had kept enough of a shim to keep things working |
| 00:04 | <Hixie> | (i still check everything into the workers svn repo, i think) |
| 00:05 | <zcorpan> | Hixie: oh i thought it was a separate source document |
| 00:05 | <Hixie> | it was |
| 00:05 | <Hixie> | but i merged it in when i was splitting everything out |
| 00:05 | <Hixie> | to make my life easier |
| 00:05 | <Hixie> | but the original source document should still be being generated |
| 00:06 | <Hixie> | so i don't see why it wouldn't still work |
| 00:13 | <zcorpan> | so Worker.onerror can receive two kinds of events: an Event when fetching the worker script fails, and an ErrorEvent when a runtime script error is not handled by the WorkerGlobalScope's onerror |
| 00:23 | <zcorpan> | r4000 next |
| 00:25 | <zcorpan> | that'll make mpilgrim happy |
| 00:28 | <Hixie> | study 2 begins! |
| 00:30 | <Lachy> | Hixie, what does the [Supplemental] extended attribute you're using in the IDL mean? It's not yet defined in webidl, and it seems redundant with the implements statement |
| 00:31 | <Hixie> | interface A { a } [Supplmental] interface B { b } A implements B; means the same as interface A { a b } |
| 00:31 | <Hixie> | whereas |
| 00:32 | <Hixie> | interface A { a } interface B { b } A implements B; results in two interface objects |
| 00:32 | <Lachy> | isn't that what the [NoInterfaceObject] one deals with? |
| 00:33 | <Hixie> | no NoInterfaceObject only means that the interface object doesn't exist |
| 00:33 | <Hixie> | with interface A { a } [NoInterfaceObject] interface B { b } A implements B; A.b doesn't exist |
| 00:37 | <zcorpan> | Hixie: i thought [Supplemental] was supposed to be used as A { a } [Supplemental] interface A { b } |
| 00:37 | <Lachy> | oh, right. That sort of makes sense, though [Supplements] doesn't really seem intuitive |
| 00:38 | <Hixie> | zcorpan: yeah that is also a way to do it |
| 00:38 | <Hixie> | there are three ways [Supplemental] works |
| 00:39 | <Hixie> | inheritance, the same interface name twice, and 'implements' |
| 00:39 | <Hixie> | depending on exactly what you want |
| 00:39 | <Lachy> | I suppose I should update Selectors API to use [Supplemental] for NodeSelector, and change the old [ImplementedOn] attributes to implements statements |
| 00:41 | <Lachy> | does that mean to define matchesSelector on the Element interface, i can write it like this: |
| 00:41 | <Lachy> | [Supplemental] |
| 00:41 | <Lachy> | Interface Element { |
| 00:41 | <Lachy> | boolean matchesSelector(in DOMString selectors); |
| 00:41 | <Lachy> | }; |
| 00:43 | <Hixie> | yeah |
| 00:45 | <Lachy> | sweet. That means I don't need to make up a silly interface name like ElementMatchesSelector just for this |
| 00:45 | <Hixie> | man, both studies so far indicate 'about' is a terrible property name to use for giving an item an ID |
| 00:46 | <Lachy> | in RDFa? |
| 00:46 | <zcorpan> | oooh, an authoring tool for canvas: http://www.webmonkey.com/blog/Turn_Your_Vector_Art_Into_Canvas-based_Animations_With_Opacity |
| 00:47 | <Lachy> | Isn't that used to reference a element with an IDREF, indicating which element the metadata is describing? |
| 00:47 | <Hixie> | Lachy: in microdata |
| 00:47 | <Hixie> | it's used to give the item a URL, equivalent to about="" from RDFa |
| 00:47 | <Lachy> | didn't know microdata had an about attribute. Did that get added recently? |
| 00:47 | <zcorpan> | not a free authoring tool, though, but then again i guess authoring tools for flash aren't free, either (or are they?) |
| 00:47 | <Hixie> | not an attribute |
| 00:47 | <Hixie> | itemprop=about |
| 00:48 | <Lachy> | oh |
| 00:48 | <Hixie> | also, both studies so far indicate that authors really have no problem with itemprop="" containing full URLs |
| 00:48 | <Hixie> | they just sail right by that without issue |
| 00:50 | <zcorpan> | what will 'about' be replaced with? |
| 00:50 | <Hixie> | guha suggested "itemid" |
| 00:50 | <Hixie> | but i dunno, not making decisions in the usability lab :-) |
| 00:52 | <zcorpan> | of course you are, but you don't admit it. you'll post the study results to the list, and after much discussion, you'll stick 'itemid' into the spec, citing the fact that there's no consensus anyway |
| 00:53 | <Philip`> | r4000 was an anti-climax :-( |
| 00:59 | <Hixie> | zcorpan: well it's highly likely that we'll use itemid, but i don't want to think about it right now |
| 00:59 | <Hixie> | zcorpan: there are other changes we'll have to make where i really don't yet know what we'll do |
| 01:09 | <zcorpan> | Hixie: yeah, i was j/k |
| 01:10 | <zcorpan> | "Personally I lean towards the second of these" - http://www.jenitennison.com/blog/node/129 |
| 01:10 | <zcorpan> | (which is "leave the creation of that DOM as implementation-defined") |
| 01:23 | <Lachy> | I have matchesSelector() essentially defined now. All it took was the IDL and one line that says: |
| 01:23 | <Lachy> | The matchesSelector() method on the Element interface must, when invoked, return true if the _context node_ is a _matching Element node_. Otherwise, the method must return false. |
| 01:23 | <Lachy> | And then a little bit of shuffling other things around in the spec to reuse what was already specified. |
| 01:47 | <Hixie> | so far no real confusion over types, despite the conversations we were having here |
| 01:47 | <Hixie> | four more studies tomorrow |
| 01:48 | <Hixie> | we're gonna try a couple with 'about' renamed to 'itemid' |
| 01:50 | <Lachy> | weinig, JohnResig http://dev.w3.org/2006/webapi/selectors-api2/#matchtesting |
| 01:51 | <othermaciej> | should we take the webkit prefix off of our impl? |
| 01:54 | <Lachy> | othermaciej, assuming this API is accepted by the group as-is, then yes, webkit's implementation is effectively fully conforming, aside from the known no-value bugs |
| 01:57 | <othermaciej> | guess we should wait a little bit to see if anyone objects to the API |
| 02:08 | <Lachy> | othermaciej, what are your thoughts on the idea of introducing a Selector object that can be used for handling the scoped selector use cases, allowing the .createSelector() factory method to handle the selector pre-processing? |
| 02:09 | <othermaciej> | Lachy: I'm not totally clear on what you are suggesting |
| 02:09 | <othermaciej> | can you give me an example? |
| 02:09 | <Lachy> | I'm thinking it might be better than introducing a whole bunch of new queryScopedSelector*() and matchesScopedSelector() interaces. |
| 02:09 | <Lachy> | sure, here's an example: |
| 02:09 | <Lachy> | wait, there's one in my mail in pubilc-webapps. I'll get the link |
| 02:10 | <Lachy> | http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1239.html |
| 02:10 | <Lachy> | see from "Interface DocumentSelector" in that mail |
| 02:12 | <othermaciej> | hmmm |
| 02:12 | <othermaciej> | if impliedScope is an optional extra parameter to createSelector, why can't it just be an optional extra parameter to querySelector*() and matchSelector()? |
| 02:12 | <othermaciej> | it seems like that would be a more streamlined API |
| 02:12 | <sicking> | Lachy: i think introducing a selector object is a good idea if we want to reduce compile times |
| 02:13 | <othermaciej> | the main advantage of Selector is if we expect someone will want to test against the same selector repeatedly, and time spent parsing the selector may be a significant part of the total cost |
| 02:13 | <sicking> | Lachy: but IMHO we should make the API such that functions, like querySelectorAll, accept either a string or a selector object |
| 02:13 | <Lachy> | having the createSelector method gives JS libraries an easy way to test for browser support |
| 02:13 | <Lachy> | sicking, yes, that was the idea |
| 02:13 | <othermaciej> | test for browser support of scoped selectors? |
| 02:13 | <othermaciej> | I guess that's true |
| 02:13 | <Lachy> | yes |
| 02:13 | <othermaciej> | but it's still needlessly awkward for simple cases |
| 02:14 | <othermaciej> | IMO |
| 02:14 | <sicking> | indeed, i think it should be possible to pass a string everywhere you can pass a selector object |
| 02:14 | <Lachy> | it might also give us a way to handle the namespace issue using the Selector object, if it can be set up with namespace resolution somehow |
| 02:14 | <othermaciej> | why should you have to say scopeElt.querySelector(Selector.createSelector("foo", scopeElt, true)) |
| 02:15 | <sicking> | Lachy: that's not a bad idea |
| 02:15 | <othermaciej> | instead of scopeElt.querySelector("foo", true) |
| 02:15 | <othermaciej> | (actually the scope element probably should not be part of the selector by default) |
| 02:15 | <Lachy> | actually, you would need to do document.querySelectorAll(document.createSelector("foo", scopeElt, true)); to give the same result as JS libraries |
| 02:16 | <sicking> | what's the 'true' argument? |
| 02:16 | <othermaciej> | I see |
| 02:16 | <othermaciej> | the "true" argument means make every selector of the selector group implicitly start with :scope |
| 02:16 | <sicking> | ah |
| 02:16 | <Lachy> | sicking, it determines if the browser should imply :scope automatically or not |
| 02:16 | <othermaciej> | but point being, I think you should be able to omit document.createSelector and the extra parens |
| 02:16 | <othermaciej> | even if we also have a Selector object |
| 02:17 | <sicking> | hmm.. i don't feel strongly regarding if scoped selectors can be done as both string and a object |
| 02:17 | <othermaciej> | because the Selector object is needless code noise unless you plan to reuse the selector |
| 02:17 | <Lachy> | fair enough |
| 02:17 | <sicking> | creating scoped selectors is mostly useful for libraries anyway |
| 02:17 | <weinig> | JohnResig: I had to make two changes to your test |
| 02:17 | <Lachy> | then I suppose we could do this: |
| 02:18 | <othermaciej> | it could also be useful for programmers who are used to the libraries but would like to code to the native API |
| 02:18 | <sicking> | othermaciej: it's really simple to add ":scope" to the beginning of your string |
| 02:18 | <weinig> | root.webkitMatchesSelector(null) === null -> root.webkitMatchesSelector(null) === false |
| 02:18 | <weinig> | root.webkitMatchesSelector(undefined) === null -> root.webkitMatchesSelector(undefined) === false |
| 02:19 | <Lachy> | NodeSelector.querySelectorAll(">em", true, scopeElement) (where scopeElement is optional and defaults to the Element it's being executed on) |
| 02:19 | sicking | wish we didn't bother with defining behavior for null and undefined until we've all agreed for a default behavior for the rest of the DOM |
| 02:19 | <othermaciej> | sicking: it is, but if we export an API to do it automatically for convenience, then it may as well be easy to use that API |
| 02:20 | <Lachy> | sicking, we ended up removing the null and undefined definitions from selectors API. it's now left entirely up to web idl |
| 02:20 | <sicking> | othermaciej: you mean to scope automatically for conveience |
| 02:20 | <sicking> | Lachy: i know, but resigs test suites still test it |
| 02:21 | <sicking> | i guess what I propose is this: |
| 02:21 | <Lachy> | should we remove it from the test suite for this version the level 1 API? |
| 02:21 | <sicking> | Lachy: imho yes |
| 02:22 | <othermaciej> | sicking: yes |
| 02:23 | <Lachy> | sicking, it's not as simple as just prefixing :scope to the beginning of the string. It requires at least basic selector parsing to do it right, cause it's a group of selectors. |
| 02:23 | <sicking> | here's what i propose: allow querySelector/querySelectorAll/matchesSelector to take a string (in which case they don't do any automatic scoping), or a Selector object. Create two functions for creating selector objects: createSelector and createScopedSelector. The latter adds an implicit ":scope" before each selector |
| 02:24 | <sicking> | Lachy: when you're typing a string, as a human, it's easy to add ":scope" as needed |
| 02:25 | <othermaciej> | yeah but if someone is used to writing ">em, >i, >span.fancy" then it seems gratuitous to make them either write ":scope>em, :scope>i, :scope>span.fancy" or construct a Selector object |
| 02:25 | <Lachy> | for compat with JS libraries and existing content, and to allow JS libraries to reduce their dependence on custom selector parsing, the API should ideally handle cases like this ">em, >strong" easily. |
| 02:25 | <othermaciej> | Boris made a pretty good case that the performance argument for selector objects is dubious |
| 02:26 | <sicking> | Lachy: why "easily" if we're talking about libraries, it's not a big burden to ask them to create an object IMHO |
| 02:27 | <Lachy> | yeah, I don't think I would do the Selector object for perf reasons. It would have to be based on what's best for authors and JS libraries to use, and what's implementable |
| 02:27 | <sicking> | othermaciej: the alternative i guess is to add extra optinal parameters to all of querySelectorAll/querySelector/matchesSelector. Or create sibling functions: querySelectorAllScoped/querySelectorScoped/matchesSelectorScoped |
| 02:28 | <Lachy> | creating additional methods gets messy, especially if we want to address the namespace issue with additional NS methods too. |
| 02:28 | <sicking> | agreed |
| 02:28 | <Lachy> | I really don't want to have to end up with queryScopedSelectorAllNS(), et al. |
| 02:29 | <josespinal> | what are the limitations of html5's data attributes? |
| 02:29 | <sicking> | but so does optional arguments if we want optional arguments to handle namespaced stuff too |
| 02:29 | <sicking> | josespinal: sky's the limit :) |
| 02:29 | <Lachy> | I know. That's why I was thinking the Selector object would be nice, since it handles it all in once place |
| 02:30 | <josespinal> | sicking, heh no limitation? |
| 02:30 | <othermaciej> | additional methods are good for feature testing compared to optional arguments, but bad for potential API explosion |
| 02:30 | <sicking> | josespinal: well, your users RAM |
| 02:30 | <sicking> | othermaciej: yup |
| 02:30 | <othermaciej> | including namespace mappings in a Selector object would be somewhat icky, since technically they are not part of the selector, they are part of the evaluation context |
| 02:30 | <josespinal> | aja |
| 02:30 | <josespinal> | ! |
| 02:31 | <Lachy> | good point. |
| 02:31 | <sicking> | othermaciej: no, they're part of parsing |
| 02:31 | <josespinal> | sicking: when getting the attributes' values with JS? |
| 02:31 | <sicking> | othermaciej: that's how XPath does it too |
| 02:31 | <Lachy> | hmm. |
| 02:32 | <othermaciej> | sicking: I guess you could think of it that way |
| 02:32 | <Lachy> | yeah, it does. I looked at the XPath stuff today. That's where I got the idea for the Selector object |
| 02:32 | <othermaciej> | anyway, I'm not categorically against an object, I just get suspicious of needlessly verbose APIs |
| 02:33 | <sicking> | i agree, i'm just not sure what a good other solution would be |
| 02:33 | <josespinal> | ? |
| 02:33 | <Lachy> | I guess all we're doing is trading one type of needless verbosity with additional NS methods, with another with slightly messier syntax |
| 02:33 | <sicking> | i do would like to let the most common cases (source-wise) to not have to use objects |
| 02:33 | <othermaciej> | it reminds me of my discussion with hsivonen recently about whether it would be more fun to write (new XMLSerializer("application/xml")).serializeToString(myElt), or myElt.xmlMarkup |
| 02:34 | <sicking> | josespinal: not sure i understand your question. The answer about RAM was mostly a joke |
| 02:34 | <sicking> | josespinal: basically there's no defined limit as far as names or values goes |
| 02:34 | <josespinal> | oh ok, dumb me |
| 02:34 | <josespinal> | ok |
| 02:34 | <josespinal> | thanks |
| 02:35 | <sicking> | josespinal: but i wouldn't try to do ridiculous things, like creating names that are hundreds of kB big |
| 02:35 | <sicking> | josespinal: or create thousands of attributes on the same element |
| 02:35 | <sicking> | josespinal: or stick GB of data into an attribute |
| 02:35 | <josespinal> | lol |
| 02:35 | <sicking> | in most those cases you're likely to run into implementation behavior |
| 02:35 | <josespinal> | got that |
| 02:36 | <sicking> | i think gecko has a pretty low limit on number of allowed attributes on a single element |
| 02:36 | <josespinal> | 8 attributes would be too much i think |
| 02:36 | <josespinal> | :P |
| 02:36 | <sicking> | yeah, we don't allow more than 1024 attributes |
| 02:37 | <sicking> | but i've never heard of anyone butting up against that. Though maybe things will change now with data attributes |
| 02:38 | <josespinal> | change how? |
| 02:39 | <sicking> | people might use more attributes and start running into the 1024 limit |
| 02:39 | <othermaciej> | I wonder what WebKit's limit is |
| 02:39 | <othermaciej> | I don't think there is any limit when using the DOM APIs but there might be one at parse time |
| 02:40 | <sicking> | we limit it at 1024 because we store the attribute count and child count in the same 32bit bitfield |
| 02:41 | <sicking> | so we use 10 bits for attr-count and 32 bits for child-count |
| 02:41 | <sicking> | err.. 22bits for child count |
| 02:43 | <josespinal> | interesting |
| 02:43 | <sicking> | hopefully the world has switched to 64bit before <input> elements get 1024 defined attributes :) |
| 02:43 | <sicking> | so far it seems like a tight race |
| 02:43 | <josespinal> | lol |
| 02:43 | <josespinal> | lets hope so |
| 02:45 | josespinal | has to run |
| 02:45 | <josespinal> | thanks for everything sicking |
| 02:45 | <sirdarckcat> | regarding CSS attribute reader from: http://krijnhoetmer.nl/irc-logs/whatwg/20090924#l-993 |
| 02:45 | <sirdarckcat> | => <annevk2> you cannot do much more than you can do already with JavaScript afaict |
| 02:45 | <sirdarckcat> | thats true, but XSS filters only protect against javascript, not CSS |
| 05:45 | <othermaciej> | Hixie: GMail is an example of a Web app that uses paste events (uses "paste" and "beforepaste" in rich text composition mode) |
| 05:46 | <othermaciej> | Hixie: likewise Google Docs (beforepaste, paste and copy) |
| 05:48 | <othermaciej> | Hixie: also Google Search |
| 05:50 | <othermaciej> | Hixie: also Yahoo Mail |
| 05:58 | <othermaciej> | Hixie: also YouTube (for some reason) |
| 06:07 | <othermaciej> | Hixie: also the wiki server software that ships with Mac OS X |
| 06:19 | <ezyang> | Does anyone remember the URL of that history viewer for the HTML5 spec? |
| 06:19 | <ezyang> | aha http://html5.org/tools/web-apps-tracker |
| 06:25 | <ezyang> | In the new "have an element in specific scope algorithm", what does "If node is the target node, terminate in a match state." mean? |
| 06:25 | <ezyang> | target node doesn't seem to refer to anything... |
| 08:40 | <Philip`> | othermaciej: Microsoft has actually posted to the WHATWG (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/014026.html) so I assume there's not a strict policy of staying away from it entirely |
| 09:02 | <othermaciej> | Philip`: hmmm, other MS folks (e.g. Chris Wilson) have said otherwise, at least as to reading the list, but perhaps the policy changed |
| 09:03 | <othermaciej> | Philip`: regardless, it's probably easier to get Microsoft input by posting to W3C lists |
| 09:07 | <annevk2> | hmm, my inbox is full of ECMA |
| 09:11 | <Rik`> | http://groups.google.com/group/base2-js/browse_thread/thread/37acf844ceeb181c html5lib by dean edwards |
| 09:16 | <annevk2> | sweet |
| 09:16 | <annevk2> | I wonder why that one guy finds IDLs hard to read |
| 09:16 | annevk2 | finds them quite convenient |
| 09:17 | annevk2 | learned how the DOM was put together by reading IDL blocks |
| 09:20 | <annevk2> | also nice, Sec-From is gone |
| 09:33 | <jgraham> | That dean edwards thing assumes <legend> in <details> |
| 09:34 | <jgraham> | Also, unrelatedly, having selector objects for caching seems unnecessary; if parsing selectors is a significant performance problem the UA should cache them automatically |
| 09:34 | jgraham | would prefer a selector-object free design in general |
| 09:35 | <annevk2> | I really wonder why we need to make it so complicated |
| 09:35 | <jgraham> | Indeed |
| 09:35 | <annevk2> | Though if we do we should really nuke DOM Traversal out of orbit |
| 09:36 | <Philip`> | Hmm, apparently it's extra impossible to implement RDFa in XSLT, because xmlns:xml="http://whateveritis"; attributes are treated precisely identically to there being no such attribute, so you can't tell whether the prefix has been explicitly bound or not |
| 09:37 | <annevk2> | doesn't rebinding xml give you a nice violation of namespace well-formedness? |
| 09:38 | <jgraham> | Philip`: Is it just xmlns:xml that doesn't work or xmlns:foo in general? |
| 09:38 | <Philip`> | jgraham: Won't there be issues with parsing being based on namespace mapping functions, so your cache would have to detect when it's passed a different function since the parse results would change? |
| 09:39 | <jgraham> | Philip`: I don't know what the plan is for namespaces |
| 09:39 | <Philip`> | annevk2: "The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name." |
| 09:40 | <Philip`> | so it's okay as long as you use the correct value |
| 09:40 | <jgraham> | Philip`: But it isn't obviously impossible to make the design cacheable |
| 09:41 | <Philip`> | jgraham: Just xmlns:xml I think - a complete implementation should allow access to namespace mappings, so xmlns:foo is okay, and the problem is just that xml is in the mapping regardless of whether it's declared |
| 09:42 | <annevk2> | Philip`, ah ok |
| 09:42 | <Philip`> | (though apparently Firefox's XSLT implementation doesn't let you access xmlns:foo at all) |
| 09:42 | jgraham | wonders if that is a problem for other tree libs e.g. lxml |
| 09:42 | <jgraham> | or XOM or whatever |
| 09:42 | <Philip`> | jgraham: Indeed - automatic caching seems to make much more sense, in terms of shifting complexity from users to implementors |
| 09:46 | <Philip`> | (Also, implementors could optimise their parsers) |
| 10:48 | jgraham | wonders how an operating system and browser implemented in pure ecmascript would work |
| 10:49 | <jgraham> | Since there is no way to access the hardware or anything |
| 10:50 | <annevk2> | yeah ... |
| 10:50 | <annevk2> | I just replied |
| 11:08 | <othermaciej> | jgraham: even taking that assumption as a given, the further conclusions don't make sense, so I decided not to argue with it |
| 11:09 | <othermaciej> | jgraham: but it does seem so hypothetical that it's not a very strong argument against API convenience |
| 11:10 | <hsivonen> | othermaciej: I noticed you had mentioned XMLSerializer in the logs |
| 11:11 | <othermaciej> | hsivonen: in reference to our old discussion, yeah |
| 11:11 | <othermaciej> | it was incidental to the topic (which was Selectors API enhancements) |
| 11:11 | <hsivonen> | othermaciej: considering possible new information since we last discussed it, what's your take on changing WebKit to serialize HTML DOMs as XML if the MySpace problem were evangelized away? |
| 11:12 | <othermaciej> | I think the fact that WebKit serializes HTML DOMs as HTML was totally an accident |
| 11:12 | <othermaciej> | and I'm surprised and alarmed that sites ever came to depend on it |
| 11:12 | <hsivonen> | othermaciej: do you consider it a fixable accident? |
| 11:13 | <othermaciej> | if MySpace is the only significant breakage, and if it can be fixed, then yes I think it is fixable |
| 11:13 | <othermaciej> | our intent was to emulate the Gecko API |
| 11:13 | <hsivonen> | othermaciej: OK. thanks. |
| 11:14 | <hsivonen> | annevk2: given what othermaciej said, can you speculate on whether Opera would align with the Gecko trunk behavior? |
| 11:15 | <hsivonen> | othermaciej: Is the failure to emulate Gecko when it comes to non-void but empty http://www.w3.org/1999/xhtml elements on the XML side deliberate, though? |
| 11:15 | <hsivonen> | I.e. WebKit does <div></div> rather than <div/> |
| 11:15 | <othermaciej> | ah |
| 11:16 | <othermaciej> | when serializing XML elements in the HTML namespace, we attempt to produce HTML-compatible XML, in all our paths for producing XML |
| 11:16 | <othermaciej> | if that created compatibility issues in specific contexts, we could change it |
| 11:16 | <hsivonen> | Yeah, I thought that was deliberate. |
| 11:17 | <othermaciej> | well, we didn't make a conscious choice to apply it to XMLSerializer specifically |
| 11:17 | <hsivonen> | so would the agreeable convergence target be taking the WebKit XML-side behavior and making it standard on both HTML and XML trees? |
| 11:17 | <othermaciej> | we decided to do that based on other contexts that serialize to XML (possibly even native APIs) and decided to do it everywhere |
| 11:17 | <hsivonen> | (so the delta to Gecko trunk would be turning <div/> into <div></div>) |
| 11:18 | <othermaciej> | I think that would make sense, if MySpace can be fixed |
| 11:18 | <hsivonen> | Great! |
| 11:18 | <hsivonen> | any views from anyone from Opera? |
| 11:18 | <othermaciej> | also for void elements we put the gratuitous space before the slash |
| 11:18 | <annevk2> | hsivonen, I'm fine with aligning |
| 11:18 | <othermaciej> | <br /> |
| 11:19 | <annevk2> | hsivonen, will you write a spec? :) |
| 11:19 | <hsivonen> | annevk2: which alignment? :-) |
| 11:19 | <annevk2> | hsivonen, with the spec :p |
| 11:20 | <annevk2> | hsivonen, I don't think we care much either way, as long as sites work, so Gecko trunk + MySpace fix would work |
| 11:20 | <hsivonen> | annevk2: I commit to writing a spec on the spot here without approval from Mozilla, but I've worked under the assumption that morally I'm on the hook for writing a spec some day |
| 11:20 | <hsivonen> | I *can't* commit |
| 11:21 | <hsivonen> | one negation makes such a difference in sentences :-( |
| 11:21 | <hsivonen> | annevk2: OK. thanks. |
| 12:27 | annevk2 | wonders if it's worth fighting the deprecation of text/xml in http://tools.ietf.org/html/draft-murata-kohn-lilley-xml and the continued bullshit of the charset defaulting to us-ascii in text/xml (is there a consumer out there other than mpilgrim_'s feedparser that implements that?) |
| 12:31 | <hsivonen> | annevk2: Validator.nu! |
| 12:32 | <hsivonen> | annevk2: and I have a checkbox in the UI that amounts to "[x] Violate RFC 3023" |
| 12:32 | <hsivonen> | and I haven't even gotten the t-shirt! :-( |
| 12:34 | <hsivonen> | annevk2: the way the IETF is dealing with the text/* default brokenness is really, really sad |
| 12:34 | <hsivonen> | big cultural difference compared to how the WHATWG does things |
| 12:35 | hsivonen | wonders if there's an experimental sociologist taking notes and at least getting a PhD. out of this |
| 12:46 | <annevk2> | hsivonen, agreed |
| 12:48 | <annevk2> | hsivonen, not sure whether to like or dislike the Validator.nu compliance :) |
| 12:48 | <annevk2> | hsivonen, I guess it's a fun easter egg |
| 13:00 | <gsnedders> | annevk2: SimplePie supports it with US-ASCII with fallback in a similar way to Universal Feed Parser |
| 13:02 | <hsivonen> | gsnedders: how does that mean it supports it if falls back onto a superset of ASCII? |
| 13:02 | <gsnedders> | hsivonen: Basically yeah. |
| 13:02 | <hsivonen> | gsnedders: does it throw a bozo exception in addition to falling back? |
| 13:03 | <gsnedders> | hsivonen: I had an impl of that, but removed that, and just haven't removed the encoding magic yet. |
| 13:04 | <jgraham> | gsnedders: BTW bibbi told me to tell you not to panic. I don't know if someone told her to tell me to tell you that or not |
| 13:04 | <gsnedders> | jgraham: She emailed me last night |
| 13:05 | <gsnedders> | jgraham: She may have got you to tell me because I'm not reading email much this month :) |
| 13:05 | <jgraham> | Yes, she said that too. Did it have the words Don't Panic enblazoned in large friendly letters at the top |
| 13:05 | <gsnedders> | No, nor on the back. |
| 13:05 | <jgraham> | ? |
| 13:06 | <gsnedders> | Well, it was on the back originally, though I don't know how you can have it on the back of an email… |
| 13:06 | <gsnedders> | Anyhow, I'm off (to prove I don't read email) |
| 13:06 | <jgraham> | Well maybe that's why she told me to tell you not to panic. It may even be why someone told her to tell me to tell you not to panic. But we don't know |
| 13:09 | jgraham | can't find any evidence that Don't Panic was written on the back as opposed to the front |
| 13:12 | <annevk2> | it's on the top of my laptops |
| 13:12 | <Lachy> | gsnedders, Don't Panic was always on the front, at least in the original radio series |
| 13:17 | jgraham | only remembers "on the cover" which was also all that a quick Google search turned up |
| 13:17 | <jgraham> | But on the fornt makes much more sense |
| 13:17 | <jgraham> | *front |
| 13:23 | hsivonen | didn't know that the "languages" side bar on wikipedia supports one-to-many mappings |
| 13:23 | <hsivonen> | for a moment there I thought I had broken the parser |
| 13:58 | <Philip`> | Aren't workers likely to import standalone script libraries, which might also be imported by non-worker scripts on the same site, and which might use non-ASCII characters? |
| 13:59 | <Philip`> | The worker scripts themselves are likely to be new, but they'll use bits and pieces of old library code |
| 14:03 | <Philip`> | Hah |
| 14:03 | <Philip`> | If I apply http://www.rddl.org/rddl2rdf.xsl to http://www.w3.org/XML/1998/namespace then the output is not namespace-well-formed XML |
| 14:03 | <Philip`> | Hooray for namespaces! |
| 14:04 | <murr5y> | \o/ |
| 14:21 | <Lachy> | My first attempt at supporting scoped selectors in Selectors API has been checked in. http://dev.w3.org/2006/webapi/selectors-api2/#the-apis |
| 14:24 | <karlushi> | http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars - This article about file type on macosx reminds me about mimetypes issues. |
| 14:25 | <Rik|work> | karlushi: ping, you got mail :) |
| 14:28 | <karlushi> | Rik about parisweb? Seen it yesterday evening but was too tired to really think about it. :) I'll reply tonight. |
| 14:31 | <annevk2> | data URLs are same origin... |
| 14:31 | <annevk2> | most of the time, anyway |
| 14:36 | <jgraham> | It seems like a worker can use a cross-origin script with the cooperation of the page anyway |
| 14:37 | <jgraham> | <script type="text/x-worker" src="http://thirdparty.example"></script>; and then .toString() the script and postMessage it to the worker which can eval it |
| 14:40 | <TabAtkins> | Sure, but it's always possible to shoot yourself in the foot. |
| 14:41 | <TabAtkins> | You could do the same by having a helper page make a cross-origin (non-JS) request for the script, and have the worker XHR and eval it. |
| 14:43 | <jgraham> | TabAtkins: I'm not advocating cross-domain workers at all but it's not obvious why this is shooting yourself in the foot |
| 14:43 | <TabAtkins> | Just in the general sense that allowing a script on a domain you don't control to run in your security context is potentially bad. |
| 14:44 | <jgraham> | Well yes, but the whole web is based on that working |
| 14:45 | <jgraham> | At least the part of the web that relies on advertising |
| 14:46 | <TabAtkins> | Yeah, and that sorta sucks. >_< |
| 14:47 | <TabAtkins> | But anyway, I doubt that advertising will be using Workers, so might as well keep it difficult to do this sort of thing. |
| 14:48 | <jgraham> | You don't envison adverts that compute the first million digits of pi in the background? |
| 14:49 | <miketaylr> | Buy viagra....π |
| 14:50 | <TabAtkins> | Hehe. |
| 14:57 | <TabAtkins> | Grah, I hate having our store hosted by someone else. It makes editting so difficult, especially when I don't actually have a login for them, and the dude I'm supposed to be sharing with (who has appropriate permissions for me to edit the store code) isn't in yet. |
| 14:57 | <hsivonen> | w00t! wikipedia got made HTML5 without the space the authoritative page |
| 14:58 | <annevk2> | zcorpan, next you should argue for a media type :) |
| 14:58 | <annevk2> | zcorpan, come to think of it, if importScripts imports ECMAscript it probably does not make much sense to always use UTF-8 |
| 14:58 | <Lachy> | hsivonen, what does "without the space the authoritative page" mean? |
| 14:58 | <annevk2> | it means HTML_5 is now named HTML5 |
| 14:59 | <annevk2> | I guess |
| 14:59 | <hsivonen> | Lachy: HTML5 used to redirect to HTML_5 |
| 14:59 | <hsivonen> | Lachy: now HTML_5 redirects to HTML5 |
| 14:59 | <Lachy> | oh |
| 14:59 | <hsivonen> | in mediawiki terms of "redirection" |
| 15:00 | <Lachy> | That's interesting, considering this that opposed it http://en.wikipedia.org/wiki/Talk:HTML5#Back_to_.22HTML5.22 |
| 15:33 | <TabAtkins> | Firefox devs: I want tearoff tabs. >_< |
| 15:34 | <TabAtkins> | Oh, nm, I have them now. |
| 15:34 | <TabAtkins> | Didn't realize this. |
| 15:38 | jgraham | isn't sure he is happy with the ECMAScript people trying to constrain API design to what is implementable in pure ECMAScript |
| 15:39 | <Philip`> | Because you don't consider that a valuable goal? |
| 15:39 | <Philip`> | It seems pretty useful for e.g. emulating new APIs in old browsers |
| 15:40 | <jgraham> | Because a) I don't understand the reason for it and b) without knowing a) it seems more useful to have well-designed APIs than artifically constrained ones |
| 15:41 | <TabAtkins> | I think Philip` provided probably the biggest practical reason. |
| 15:41 | <jgraham> | Philip`: In many cases new APIs can't really be emulated in old browsers anyway |
| 15:41 | <TabAtkins> | I don't think the idea that an OS might be implemented in ecmascript is very important to worry about, though. |
| 15:41 | <Philip`> | jgraham: In many cases you can make a good enough approximation for people to survive |
| 15:41 | <Philip`> | e.g. with <canvas> |
| 15:41 | <jgraham> | Philip`: What about localStorage? |
| 15:42 | <Philip`> | or you could use Flash as the backend implementation |
| 15:42 | <Philip`> | jgraham: Maybe Flash, or cookies, or use a remote web service for persistent storage |
| 15:43 | <TabAtkins> | And there's that crazy window.name hack for SessionStorage. |
| 15:43 | <jgraham> | In any case this seems like a tradeoff for the HTML WG to make on a case-by-case basis, not one for TC39 to insist on as a blanket restriction |
| 15:43 | <Philip`> | "we believe that new host APIs should generally seek to avoid requiring catchalls" sounds a long way from a blanket restriction |
| 15:44 | <jgraham> | Philip`: Depends whether by "generally" they mean "always" or "unless they make sense" |
| 15:44 | <Philip`> | (Implementing localStorage via a remote storage service would be excellently ironic, unless I'm forgetting what "ironic" means) |
| 15:45 | <TabAtkins> | I think that's irony, yes. |
| 15:45 | <TabAtkins> | Also: ecma just needs __get magic like PHP and Ruby have. Then catchalls won't be a problem. |
| 15:45 | <jgraham> | I thought Americans didn't get irony? ;) |
| 15:45 | <Philip`> | jgraham: Well, if "generally" means "always", and "should" means "must", and "seek to avoid" means "don't"... |
| 15:46 | <Philip`> | I suppose then it would be a blanket restriction |
| 15:46 | <jgraham> | Philip`: Well they clearly don't like something in HTML5. And it's not like there are dozens of places where catchalls have been used |
| 15:46 | <Philip`> | ("Blanket restriction" sounds like something you get during wartime rationing when there's not enough cloth to go around) |
| 15:47 | <jgraham> | So I would conclude that the restriction they have in mind is severe enough that one of the rather few instances of a new API that uses this pattern is enough to violate it |
| 15:48 | <jgraham> | TabAtkins: Yeah they have been arguning about the precise way to implemtn catchalls for as long as I can remember |
| 15:48 | <TabAtkins> | Man, it ain't hard. |
| 15:48 | <jgraham> | Which, admittedly isn't very long in this case |
| 15:49 | <Philip`> | Yeah, they should just copy all of PHP's design decisions |
| 15:49 | <TabAtkins> | I'm glad you see things our way, Philip`. |
| 15:49 | <TabAtkins> | Anyway, it's *also* Ruby's design decision. |
| 15:49 | <jgraham> | http://wiki.ecmascript.org/doku.php?id=strawman:catchalls |
| 15:49 | <jgraham> | Python has __getattr__ |
| 15:49 | <Philip`> | I think they should randomise the function naming conventions in the next version of ECMAScript too |
| 15:51 | jgraham | can't say he is super-thrilled by a proposal wehich appears to require first creating an object and then defining the catchalls on it seperatly |
| 15:51 | <TabAtkins> | Man, Philip`, my heart flutters at the mere possibility. |
| 15:52 | <TabAtkins> | (Though function naming isn't that bad. It's the *argument ordering* that really drives me crazy.) |
| 15:53 | <TabAtkins> | (Like in_array and substr taking the needle and haystack in opposite order.) |
| 15:54 | Philip` | wonders where the terms needle/haystack originated, in the context of search algorithms |
| 15:54 | <TabAtkins> | Can a page on a secure connection link to a resource on another, different secure connection without raising the security dialog? |
| 15:54 | <Dashiva> | TabAtkins: It's also annoying that some functions are whatnot and others are array_whatnot |
| 15:55 | <TabAtkins> | Philip`, isn't it obvious? The needle/haystack metaphor has been around forever. |
| 15:55 | <Philip`> | I don't remember hearing it more than a few years ago |
| 15:55 | <TabAtkins> | Dashiva: Yeah, but honestly, that just doesn't bother me that much. I've learned enough langauges that names just slide in. |
| 15:55 | <TabAtkins> | "Like finding a needle in a haystack"? |
| 15:55 | <TabAtkins> | That's an old, old expression. |
| 15:56 | <TabAtkins> | Denotes a difficult search. |
| 15:56 | <Philip`> | I know the expression, but not its adoption into search algorithms |
| 15:57 | <TabAtkins> | Philip`, as far as I know it's been around for a long time there as well. Been in every literature I've read since I started programming. |
| 15:57 | <Dashiva> | It seems like a no-brainer |
| 15:57 | <TabAtkins> | (Which, admittedly, is only like 10 years ago or so.) |
| 15:57 | <Philip`> | http://www.manpagez.com/man/3/strstr/ just uses s1,s2, but http://linux.die.net/man/3/strstr uses haystack,needle |
| 15:59 | <TabAtkins> | So, I'm trying to decide if I can fake out the security dialog. I have a page on a secure connection on a server that I have little control over, and probably no ability to store arbitrary files. I also have a handy secure site which I *do* have completely control over already set up. |
| 15:59 | <TabAtkins> | I wanna use the latter to host files for the former to link to, if it'll make the browser shut up about linking to insecure resources. |
| 16:00 | <Philip`> | Hmm, apparently glibc documentation used haystack/needle since at least 1995 |
| 16:01 | <Philip`> | but I'm sure I never heard it until relatively recently |
| 16:01 | <hsivonen> | Philip`: haystack/needle is ancient |
| 16:01 | <TabAtkins> | Define 'recently'. |
| 16:02 | <Philip`> | TabAtkins: Recently enough that I can remember thinking "ooh, that's a good name for the arguments" when I first noticed it |
| 16:02 | <TabAtkins> | Heh, k. |
| 16:02 | <TabAtkins> | Yeah, your brain is just crazy, then. |
| 16:02 | <hsivonen> | I'm pretty sure it appears in at least one of Boyer–Moore, Rabin–Karp or Knuth–Morris–Pratt papers |
| 16:03 | <TabAtkins> | Woo, awesome, hosting on an unrelated secure server works. |
| 16:05 | <Philip`> | TabAtkins: Does the browser UI still indicate that the site is secure? (like when it shows the name of the site in a green/yellow box in the address bar, or whatever) |
| 16:06 | Philip` | has seen lots of secure sites where Opera just shows a grey "?" because it doesn't trust all the content on the page |
| 16:06 | <Philip`> | (which is particularly annoying when they're pages asking for my credit card details) |
| 16:06 | <TabAtkins> | Philip`, I'm viewing in IE, since it has the dialog most likely to produce a broken page (clicking "yes" makes it ignore all the insecure items). |
| 16:06 | <TabAtkins> | So, maybe? |
| 16:06 | <TabAtkins> | Anyway, got lots and lots of stuff to push over and change links for now. |
| 16:07 | <TabAtkins> | I just confirmed that the template CSS is working, which made me happy. |
| 16:07 | <TabAtkins> | Because ie8 users were getting a style-less, image-less page. |
| 16:07 | <TabAtkins> | (still usable, but no one who saw it wanted to, because they were confused) |
| 16:52 | <TabAtkins> | Philip`, now that everything is being delivered securely, it does indeed indicate that it's a secure connection. |
| 16:52 | <TabAtkins> | FF and IE agree. |
| 17:10 | <Hixie> | study three |
| 18:10 | <Hixie> | well that was interesting |
| 18:11 | <gsnedders> | I agree. |
| 18:12 | <Hixie> | she was doing variant 002 |
| 18:12 | <Hixie> | she didn't get the idea of scoping at all, until we showed her the variant 003 syntax, and she was like "oooh, itemscope="", yes!" |
| 18:12 | <Hixie> | also she had huge trouble with the idea of using URLs for identifiers |
| 18:12 | <Hixie> | unlike the other two, who were fine with it |
| 18:13 | <Hixie> | we were hoping to learn more about types, but she didn't really comment on them |
| 18:13 | <Hixie> | so that didn't help much |
| 18:15 | <annevk2> | how many people are participating in total? |
| 18:17 | <Hixie> | 2 yesterday, 3 today |
| 18:17 | <Hixie> | maybe 2 more monday |
| 18:21 | <erlehmann> | Hixie, are you employing a social scientist or usability psychologist for that ? |
| 18:21 | <erlehmann> | or is it just … "well, lets see" |
| 18:21 | <Hixie> | erlehmann: yes, we have a team of usability experts here |
| 18:22 | <Hixie> | erlehmann: with recruiters, screeners, moderators, script writers, etc |
| 18:22 | <erlehmann> | script writers ? the'll miss <dialog>, for sure *smirk* |
| 18:22 | <Hixie> | one-way glass, eye tracking (though we're not using the eye tracking in this case), etc |
| 18:22 | <erlehmann> | oh wow |
| 18:23 | <Hixie> | actually usability study scripts tend to just be <li> elements :-) |
| 18:23 | <Hixie> | it's quite the setup |
| 18:23 | <erlehmann> | Hixie, your description fits my game taste perfectly. played ascii portal yet ? |
| 18:23 | <Hixie> | (i was hoping we'd be able to make the videos public, but it looks like we can't because the participants only grant us rights to use the videos internally) |
| 18:24 | <erlehmann> | oh, how sad. |
| 18:24 | <Hixie> | (though apparently if people want to see them i can show them to you if you come here and agree to the standard visitor NDAs) |
| 18:24 | <erlehmann> | "here" ? norway ? |
| 18:27 | <gsnedders> | erlehmann: Google, Mountain View |
| 18:28 | <erlehmann> | gsnedders, i was going by whois information, but that seems logical, yes. |
| 18:29 | <gsnedders> | erlehmann: Hixie runs IRC on some box in Norway because that's where he has a reliable computer he can run IRC over ssh on :P |
| 18:37 | masinter | in TAG meeting only available at interrupt |
| 18:58 | <Philip`> | I suppose one problem is you get no idea about long-term usability |
| 18:59 | <Philip`> | like whether verbose identifiers become really annoying after you've had to copy-and-paste them for the hundredth time into your document |
| 18:59 | <Hixie> | yeah |
| 18:59 | <Hixie> | that is a huge problem, indeed |
| 18:59 | <Hixie> | though we have learnt that authors have no problem with copy and paste |
| 18:59 | <Hixie> | 3 out of 3 authors so far have happily used context menus and copy and paste without any difficulty whatsoever |
| 19:00 | <Philip`> | If I remember correctly, hsivonen complains about having to copy-and-paste namespace URIs even when he only has to have them once per document |
| 19:00 | <Philip`> | and with complex embedded data you might have a dozen different identifiers each used a dozen times on the page |
| 19:01 | <Philip`> | I presume the problem is more about finding a place to copy from, rather than the mechanism of copy-and-paste |
| 19:02 | <Hixie> | yup |
| 19:02 | <Hixie> | totally agree |
| 19:02 | <Philip`> | So I guess your data won't be convincing evidence against the need for CURIEs |
| 19:02 | <Philip`> | so RDFa wins again! |
| 19:04 | <solepixel> | ok, IE8. What gives? All my html5 tags don't work, or they're being displayed "inline" or something. I have a reset stylesheet which is setting them all to display:block, but that's not taking. Is there something I should know about this issue? |
| 19:04 | <Hixie> | oh we're not trying to study rdfa here |
| 19:05 | <erlehmann> | solepixel, google frame ;) |
| 19:05 | <erlehmann> | Hixie, isn't 3 a really small number for extrapolation ? |
| 19:06 | <erlehmann> | or do you just want to uncover problems ? |
| 19:06 | <inimino> | solepixel: you probably want the createElement hack |
| 19:06 | <solepixel> | ouch |
| 19:06 | <solepixel> | so my html5 requires JS to run in IE8? |
| 19:08 | <da3d> | solepixel: You want http://html5shiv.googlecode.com/svn/trunk/html5.js |
| 19:08 | <solepixel> | so, what you're saying is, this HTML5 that everyone's saying is OK to use "today" isn't really without this javascript hack? |
| 19:09 | Philip` | wonders how the word "shiv" got so entrenched here |
| 19:09 | masinter | notes productive discussion of copy/paste difficulty as requirement has been useful, but that 'authors using text editors' are only small segment of market that create HTML pages |
| 19:09 | <inimino> | solepixel: HTML5 features are fine to use in browsers that support them |
| 19:10 | <inimino> | solepixel: if you heard that IE8 is supporting a lot of new HTML5 features, you were misinformed |
| 19:11 | <masinter> | noting things that interfere with backward compatibility with large deployed base of existing browsers would be really helpful, most standards updates take compatibility with all sides (producers and consumers) and not just one side (old producers, i.e., existing web pages) |
| 19:11 | masinter | goes back to TAG meeting |
| 19:11 | <solepixel> | no, i just saw in numerous blogs/sites that people say "yes, start using HTML5". yet they all failed to mention hacks were required for IE8 |
| 19:11 | <hsivonen> | Philip`: I use assistive technology for writing ns uris |
| 19:12 | <masinter> | they were misinformed: http://www.w3.org/QA/2009/05/_watching_the_google_io.html |
| 19:12 | <hsivonen> | Philip`: I have a program that hooks into the accessibility APIs and expands nmemonics into full uris for me |
| 19:12 | <solepixel> | John Resig being one of them |
| 19:13 | <hsivonen> | however, I had a typo in the Xlink macro, so teh wrong ns got expanded all over the place. including the V.nu talisman checking |
| 19:14 | <hober> | paul_irish_: nice post re: chrome & @font-face |
| 19:17 | <paul_irish_> | hober: oh thanks man! :) |
| 19:19 | <hsivonen> | hober: URL? |
| 19:19 | <paul_irish_> | http://paulirish.com/2009/chrome-and-font-face-a-summary/ |
| 19:26 | <hsivonen> | paul_irish_: thanks |
| 19:26 | <paul_irish_> | :) |
| 19:36 | <masinter> | http://www.w3.org/html/wg/tracker/issues/53 |
| 19:39 | <masinter> | http://dev.w3.org/html5/spec/Overview.html#text-html |
| 19:39 | <Hixie> | erlehmann: 2 yesterday, 3 today, 2 monday. turns out more than 6 is actually not that much more information. |
| 19:42 | <erlehmann> | Hixie, and from what background did you pick your candidates ? web developers ? |
| 19:42 | <Hixie> | yeah, engineers and web devs. we have a recruiting department, they ask screening questions to try to get people familiar with html but not familiar with html5, etc |
| 19:43 | <Hixie> | asking questions like "what text editor do you use" and "how much do you use css" |
| 19:43 | <Hixie> | we figured that would help weed out the wysiwyg users a bit |
| 19:44 | <erlehmann> | Well, then i'll go for „MS Word“ and „I liked Counterstrike 1.6 more.“ :p |
| 19:45 | <gsnedders> | It's cool Google are doing this, though. |
| 19:58 | <hsivonen> | hehe. jd has already drawn parallels between Silverlight and Chrome Frame |
| 19:58 | <erlehmann> | Hixie, was usability testing also employed in other regards, like naming the URI input type "url" etc. ? |
| 19:58 | <erlehmann> | or is this a first for the spec ? |
| 20:00 | <masinter> | the idea of studying this is bizarre, to pick the spec point by point for usability |
| 20:00 | <masinter> | that's like having an application user interface and asking people if they like blue or green menu items better |
| 20:02 | <Hixie> | erlehmann: first time for html5 |
| 20:03 | <erlehmann> | well i guess there wont be a second time then ? after all, other issues are not so complicated and last call is near. |
| 20:03 | <Hixie> | masinter: you wouldn't ask them which they prefer, you'd test which makes them more productive |
| 20:03 | <othermaciej> | it's not like asking, it's like doing a usability test to see if blue or green menu items are for whatever reason easier to use |
| 20:03 | <masinter> | if the criteria is 'consistency' and 'coherence', there's no way to discover that by asking piece by piece whether the overall language makes sense from a usability point of view |
| 20:03 | <othermaciej> | the latter may still be trivial and perhaps likely to produce more statistical noise than meaningful results, but at least it would not be fallacious |
| 20:03 | <Hixie> | masinter: (and google does do that; we've even doing A/B comparison studies for shades of blue on the search results page!) |
| 20:04 | <Hixie> | masinter: we don't ask them what they think, we make them do exercises and see how well they do with different variants |
| 20:04 | <Hixie> | masinter: you can see the scripts we use here: http://damowmow.com/playground/microdata/ |
| 20:04 | <masinter> | my comment about consistency and coherence of the overall language stand, no matter how you judge individual features |
| 20:04 | <othermaciej> | and when doing usability testing, yes, it does make sense to consider only one or a few features / tasks at a time |
| 20:04 | <Hixie> | participant 4 just started, following this script: http://damowmow.com/playground/microdata/script-participant5 |
| 20:04 | <Hixie> | er, participant 5 even |
| 20:05 | <masinter> | maciej: tasks, yes. features, no |
| 20:05 | <erlehmann> | masinter, html5 is not consistent at all. film at 11. |
| 20:05 | <Hixie> | though it's the fourth person, we're doing them out of order because someone canceled on us earlier today |
| 20:05 | <masinter> | i'm not saying that doing experiments is bad, it's just drawing grand conclusions based on them |
| 20:05 | <othermaciej> | judging consistency and coherence of the whole language is useful, but not in the same way as using usability testing |
| 20:06 | <othermaciej> | usability testing can't generally tell you if your whole UI paradigm is wrong (if we take it back to its usual domain) |
| 20:06 | <Hixie> | oh actually we're using script 6 with this participant (http://damowmow.com/playground/microdata/script-participant6) |
| 20:06 | <masinter> | are there any reliable statistics about percentage of web pages served that are actually hand-authored, vs. generated by database tools? |
| 20:06 | <Hixie> | my bad |
| 20:06 | <othermaciej> | you have to have good judgment to get the right basic ideas in the UI, and then you can use usability testing to refine them |
| 20:06 | <masinter> | or built with wysiwyg tools, such as rich text email editors? |
| 20:07 | <Hixie> | othermaciej: it can tell you your paradigm isn't working, though it can't tell you how to fix the whole paradigm, i'd say |
| 20:07 | <masinter> | just the relative importance given in the language design to hackers using emails to build HTML |
| 20:07 | <masinter> | s/email/emacs/ |
| 20:07 | <othermaciej> | Hixie: fair enough, though if you have a design that broken, then you need a good designer more than you need usability testing |
| 20:08 | <Hixie> | othermaciej: no argument there! |
| 20:08 | <TabAtkins> | Hixie: What are the differences between 001 and 002? I can't tell on a quick visual diff. |
| 20:08 | <othermaciej> | masinter: enough people (and in particular enough early adopters and educators/advocates) hand-author that it's worth considering |
| 20:08 | masinter | thinks extensibility, coherence, reliability of processing, locality of effects of processing, debugability etc. are more important in language design than usability, even for markup languages |
| 20:09 | <othermaciej> | I think there's generally an assumption that making something nicer for hand-authoring will not materially harm the ability of tools to produce it |
| 20:09 | <Hixie> | TabAtkins: http://damowmow.com/playground/microdata/002-001 explains going from 002 to 001 |
| 20:09 | <masinter> | more pages are edited and debugged than are authored in the first place |
| 20:09 | <othermaciej> | sure, so making HTML write-only like Perl would be a poor choice |
| 20:10 | <masinter> | that was the argument for programming languages too: programmers spend more time trying to figure out what someone else's code than they do writing stuff in the first place |
| 20:10 | <othermaciej> | though we are constrained by legacy to have some details that may be hard for a non-expert to infer from reading |
| 20:11 | <othermaciej> | for example, without knowing what elements implicitly close what other elements, and which elements are void it may be hard to read markup that doesn't go out of its way to indicate when things are closed |
| 20:11 | <Hixie> | othermaciej: the good news on that front is that authors are finding reading microdata easier than writing it |
| 20:11 | <othermaciej> | Hixie: are there any tests that involve them taking existing microdata markup and changing it to say something else? |
| 20:12 | <masinter> | or just figuring out what it says and whether it says what you think it says? |
| 20:12 | <masinter> | or debugging "i got out X and I meant for it to say Y, fix it?" |
| 20:12 | <othermaciej> | masinter: Hixie did say there are tests for reading microdata which are going well |
| 20:12 | <Hixie> | othermaciej: one exercise has them writing out the name-value pairs of http://damowmow.com/playground/microdata/002/flickr-annotated.html |
| 20:12 | <masinter> | debugging is much different from reading |
| 20:13 | <Hixie> | othermaciej: and the main other exercise is getting them to annotate http://damowmow.com/playground/microdata/002/blog.html |
| 20:13 | <masinter> | metadata is more likely to be inserted using database publishing, anyway |
| 20:14 | <masinter> | hand-authored metadata is likely to be rare anyway; the most important use cases for adding metadata to web pages come from database publishing, so the relevance of usability here is really suspect |
| 20:14 | <othermaciej> | masinter: many authors hand-author microdata markup, or templates that contain it, so I doubt your conclusion |
| 20:14 | <masinter> | i asked for statistics and you say 'many' |
| 20:15 | <othermaciej> | many authors also try to hand-author RDFa markup or templates containing it |
| 20:15 | <masinter> | now, i don't have statistics either, but i know about metadata through authoring tool chains and most of the metadata is added automatically in all of the workflows i know of, by the tools |
| 20:16 | Philip` | doesn't know how you could do something like RDFa/microdata without a human writing either the markup or the markup templates |
| 20:16 | <othermaciej> | I understand that you doubt the value of this usability study, but pre-emptively criticizing its conclusions does not seem like a good use of time |
| 20:16 | <masinter> | i'm not criticizing its conclusions |
| 20:16 | <masinter> | not at all, sorry if that seemed like i was saying |
| 20:17 | <othermaciej> | "i'm not saying that doing experiments is bad, it's just drawing grand conclusions based on them" |
| 20:17 | <masinter> | exactly, i don't expect there to be any grand conclusions, do you? |
| 20:17 | <Hixie> | i would imagine most pages that have microformats, rdfa, or that will have microdata, are either written by hand, or autofilled into templates that are themselves written by hand |
| 20:17 | <othermaciej> | I expect there to be modest conclusions, which are nontheless useful |
| 20:17 | <othermaciej> | since that is what usually happens with usability studies |
| 20:17 | <Hixie> | e.g. wordpress, a big producer of microformats, is all hand-written templates |
| 20:18 | <masinter> | othermaciej: yes, that's what i expect too, so we agree |
| 20:18 | <masinter> | hmmm, hand-written templates... that sounds right |
| 20:18 | <othermaciej> | it sounded like you were pre-emptively mocking the conclusions as likely to be "grand", when no one had presented any conclusions |
| 20:18 | <masinter> | so template builders don't actually verify the metadata accuracy |
| 20:19 | <hsivonen> | masinter: someone hand authors the templates that are filled from a database |
| 20:19 | <masinter> | hsivonen: yes, that sounds reasonable. but then, the task of changing the metadata based on looking at the HTML wouldn't be the right test. |
| 20:19 | <othermaciej> | you want markup that someone can add to a template with low likelihood of messing up the syntax (relative to alternatives) |
| 20:20 | <hsivonen> | othermaciej: I'd posit that the power of Selectors makes it super-hard to make a WYSIWYG tool that ingests hand-written CSS |
| 20:20 | <othermaciej> | a test to make a template would probably be more confusing than a test to add some concrete microdata, and unlikely to give interestingly different conclusions |
| 20:20 | <TabAtkins> | hsivonen: I'd agree with that. |
| 20:20 | <masinter> | if the metadata is populated by filling in a template, then the production of the metadata would be split between the template writer, the author of the software that knows how to fill in the template, the user that fills in the template |
| 20:20 | <othermaciej> | hsivonen: are you saying this is a consequence of the wonderful hand-authorability of Selectors? |
| 20:20 | <TabAtkins> | hsivonen: I also wouldn't care, because Selectors are so awesome. |
| 20:22 | <hsivonen> | othermaciej: abstractions that help hand authoring are hard for stuff that crams that stuff into different abstractions |
| 20:22 | <othermaciej> | hsivonen: selectors of nontrivial complexity are hard to hand-author |
| 20:23 | <hsivonen> | how does OpenOffice.org expose RDFa in ODF in the UI? |
| 20:23 | <othermaciej> | I think the real tradeoff we are seeing here is language expressiveness vs. ability of tools to understand the language and express it in a GUI |
| 20:23 | <masinter> | it's great to do usability studies, and looking at hand authoring is fine, it's just that if there are limited resources to do them, doing usability studies that correspond the most important use cases would be really helpful |
| 20:23 | Hixie | takes back what he said earlier about participants being able to extract data easily |
| 20:24 | <Hixie> | masinter: i encourage adobe to put up the resources to do usability studies for what you think is more important |
| 20:24 | <masinter> | that's a great rejoinder, of course |
| 20:24 | <hsivonen> | do adobe products expose a UI for arbitrary graphs in XMP? |
| 20:24 | <othermaciej> | masinter: if you have ideas for studies perhaps we can even find resources elsewhere |
| 20:24 | <Hixie> | it's not meant as a rejoinder, i'm serious, it would be awesome if adobe could do usability studies |
| 20:25 | <masinter> | hsivonen: I don't think so |
| 20:25 | <othermaciej> | myself, I'm not inclined to criticize data gathering simply because there is other data we could have gathered |
| 20:25 | <masinter> | Adobe mainly does WYSIWYG tools for designers |
| 20:25 | <masinter> | and for the most part, Adobe customers could care less about the markup language and don't want to see it |
| 20:26 | <masinter> | i'm sorry if it sounded like i was criticizing data gathering, i was just trying to be helpful |
| 20:26 | TabAtkins | wishes he can a bit more visibility into the markup language of PDFs, as he's been staring at a big problem for a while and Adobe tech support couldn't help him. |
| 20:26 | <hsivonen> | masinter: what happens if a file comes in from a non-Adobe app and has a complex RDF graph in XMP? |
| 20:26 | <TabAtkins> | s/can/could have/ |
| 20:27 | <othermaciej> | would you imagine any of Adobe's tools ever having UI to add metadata markup (either concrete or templates)? |
| 20:27 | <othermaciej> | or is that something that would be left to be done after the fact by editing the tool's output? |
| 20:28 | <masinter> | most adobe tools have UI to add and edit matadata, and to do template-based creation of metadata |
| 20:28 | <othermaciej> | embedded metadata, or whole-document level metadata? |
| 20:28 | <masinter> | and extensibility points for adding new menus, screens, user interfaces |
| 20:28 | <othermaciej> | and if the former, what formats are supported? |
| 20:28 | <masinter> | well, it depends on the product, maciej |
| 20:29 | <othermaciej> | I'm asking because I wonder if there is anything we can do in the design of metadata markup to make it easier for WYSIWYG tools to apply it |
| 20:29 | <tantek> | masinter, what formats in total (across any/all products)? |
| 20:29 | <masinter> | lemme give you some references |
| 20:29 | <othermaciej> | I can imagine building a template with a graphical tool and then producing pages using that template from a database is a likely scenario |
| 20:30 | <masinter> | http://www.adobe.com/products/xmp/standards.html |
| 20:30 | TabAtkins | finds Selectors absolutely trivial, and so is definitely not the guy you should ask about Selector usability. |
| 20:31 | masinter | is in a discussion in TAG meeting needs to get back, will send file format issue |
| 20:31 | <hsivonen> | tantek: are you aware of WYSIWYGish tools that support DRY metadata in document body? |
| 20:31 | <othermaciej> | so XMP is file-scope metadata? |
| 20:31 | <othermaciej> | (if I'm reading this right) |
| 20:32 | <hsivonen> | having a WYSIWYG UI for DRY seems like a hard problem |
| 20:32 | <masinter> | part 3 http://www.adobe.com/devnet/xmp/ |
| 20:32 | <masinter> | part 3 has file formats supported |
| 20:33 | <masinter> | http://www.adobe.com/devnet/xmp/pdfs/XMP-FileInfo-SDK-Overview.pdf has info on how to customize application UI for wysiwyg interfaces for custom metadata |
| 20:34 | <masinter> | PDF, InDesign and some other formats allow XMP inside embedded objects |
| 20:35 | <masinter> | http://www.adobe.com/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf says it's about dynamic media (video & audio) but it actually is a general architecture for having embedded metadata for compound objects |
| 20:35 | <masinter> | DRY = ?? |
| 20:35 | <othermaciej> | Don't Repeat Yourself |
| 20:35 | <masinter> | tantek: file formats extensible, of course |
| 20:36 | hsivonen | wonder what app consume Illustrator-written metadata in SVG |
| 20:36 | <Hixie> | well this study is going poorly |
| 20:36 | tantek | dislikes the term metadata as its often unnecessarily used (where "data" would do), and seems to encourage separation/duplication from the actual data (violations of DRY) and invisible metadata. |
| 20:36 | <hsivonen> | (parts of it have a write-only flavor) |
| 20:37 | <tantek> | here's a good blog post on the overuse of the term metadata (even/especially by CS types) http://blogs.fluidinfo.com/fluidDB/2009/09/05/metadata-vs-data-a-wholly-artificial-distinction/ |
| 20:37 | <masinter> | http://www.metadataworkinggroup.org/ working on integration of XMP with other legacy metadata formats for images & video (e.g., EXIF) so cameras can add metadata when the picture is taken |
| 20:38 | <Philip`> | Everything is cooler when you call it meta |
| 20:38 | <tantek> | Philip`: Everything is cooler when you call it Semantic |
| 20:38 | <TabAtkins> | You can't spell Semantic without meta. |
| 20:39 | <TabAtkins> | Also: You can't spell it without snic. |
| 20:39 | <Philip`> | Clearly we need metasemantics |
| 20:39 | <Hixie> | you can't spell Semantics without Antics |
| 20:40 | <TabAtkins> | http://wordsmith.org/anagram/anagram.cgi?anagram=semantic&t=1000&a=n |
| 20:40 | <TabAtkins> | You can't spell semantic without ace mints. |
| 20:41 | <Hixie> | wow, current participant is confusing me |
| 20:42 | <othermaciej> | if you call something "metadata" instead of "data", sometimes people are less insistent on figuring out how it is useful and who will use it |
| 20:42 | <TabAtkins> | othermaciej: Because you can always use more metadata. |
| 20:42 | <Hixie> | othermaciej: indeed, that's why i stopped calling things metadata a few months ago :-) |
| 20:43 | <masinter> | i think calling it 'metadata' rather than 'data' narrows the focus usefully |
| 20:43 | <masinter> | brb |
| 20:47 | <Hixie> | ok well the current participant really had trouble with containership like hte one earlier today |
| 20:47 | <Hixie> | but seemed to handle the itemtype="" idea reasonably well in the middle of all that |
| 20:47 | <tantek> | Hixie - hierarchy is always difficult, even if it is just one level (containership) |
| 20:47 | <tantek> | this is something we have learned from microformats experience as well, and as a result have worked on flattening various things |
| 20:47 | <Hixie> | so it seems |
| 20:48 | <tantek> | some of these changes are making it into hCard 1.0.1 and hCalendar 1.0.1 |
| 20:48 | <tantek> | also a big lesson: no required properties |
| 20:48 | <Hixie> | the one earlier today said that the variant 003 idea of using itemscope="" actually made things easier |
| 20:48 | <tantek> | this is a tough one for semantic/formats-heads |
| 20:48 | <Hixie> | which i found interesting |
| 20:48 | <tantek> | its is the direct OPPOSITE of draconian handling methodology |
| 20:48 | <Hixie> | like, he didn't get <div item> at all, but once we had <div itemscope>, suddenly he was much happier with it |
| 20:50 | <tantek> | Hixie - that kind of terminology specific result depends *heavily* on the background of the person |
| 20:50 | <tantek> | (I know this from seeing similar results (v�t widely varying - from numerous people in classroom settings ) |
| 20:50 | <tantek> | so another person will be much happier with "item" who has no idea what "scope" means |
| 20:51 | <tantek> | don't get me wrong - i'm happy to see you are doing this study and gathering data from it |
| 20:51 | <tantek> | it's quite useful to have various experiences confirmed by study etc. |
| 20:53 | <hsivonen> | wow. http://downforeveryoneorjustme.com/amazon.com |
| 20:53 | <othermaciej> | looks fine to me |
| 20:53 | <Philip`> | To me too |
| 20:53 | <TabAtkins> | Me too. |
| 20:54 | <TabAtkins> | So, it's down for just them? |
| 20:54 | <tantek> | maybe amazon blocked them? |
| 20:54 | <hsivonen> | amazon times out for me |
| 20:56 | <TabAtkins> | Huh. Chrome and FF agree on rendering this table-* example wrong. |
| 20:56 | <TabAtkins> | Well, maybe form elements aren't allowed to be display:table-cell. |
| 20:56 | <TabAtkins> | Which would explain things. |
| 20:58 | <TabAtkins> | Well, it wouldn't explain FF's behavior, but it's a *really* big table. |
| 21:55 | <Lachy> | JohnResig, yt? |
| 21:59 | <Lachy> | I'll respond to your mail in more detail later, but I think you've failed to see just how flexible my proposal for selectors api actually is. In fact, it seems to address most, if not all, of your needs for the API, including scoped selectors and collective queries on node lists |
| 22:12 | <TabAtkins> | Jeezus, it seems 1 in 5 sites on the web use jQuery. Of the ones that actually use js, 1 in 3 are using jquery. (I guess that means 60% of all sites on the web are using js in some way?) |
| 22:36 | <AryehGregor> | TabAtkins, I'd believe that 1 in 5 web page *views* use jQuery, but there's a *really* long tail if you count by sites. |
| 22:37 | <TabAtkins> | I'm just going by the stats cited by Resig & co during some recent talks. |
| 22:37 | <TabAtkins> | So that may be views, dunno. |
| 22:38 | <TabAtkins> | And yeah, given the number of pages Hixie bandies about (1 trillion), that's a *very* long tail. |
| 22:38 | <tantek> | pages != views |
| 22:39 | <TabAtkins> | But then again, sites != pages either. |
| 22:40 | <TabAtkins> | http://ejohn.org/blog/talks-at-the-2009-jquery-conference/ "State of jQuery '09", slide 16 |
| 22:53 | <Rik`> | i kind of doubt a source like http://trends.builtwith.com/ |
| 22:53 | <Rik`> | I can't find a description of the process to gather such data |
| 22:55 | <TabAtkins> | Well, it looks like they're only covering 3M sites, so I suppose we're mainly talking stuff you can access relatively easily with a spider. |
| 22:57 | <TabAtkins> | They do make very pretty pie charts, though, so obviously you can trust them. |
| 23:03 | <Hixie> | ok next participant |
| 23:03 | <Hixie> | this one apparently uses vim(1) |
| 23:03 | <Hixie> | which is promising |
| 23:03 | <Philip`> | Burn him/her! |
| 23:04 | <Hixie> | better than frontpage! |
| 23:04 | <hsivonen> | Hixie: do they bring their own laptop or .vimrc (or whatever the pref file is called)? |
| 23:05 | TabAtkins | just uses a normal text editor. |
| 23:05 | <Philip`> | TabAtkins: 5% of pages in the dotnetdotcom sample have <script src="*jquery*"> |
| 23:05 | <Philip`> | which is a long way from 20% |
| 23:05 | <Philip`> | (though still quite a lot) |
| 23:05 | <Hixie> | hsivonen: nah, we make them use some random text editor |
| 23:05 | <TabAtkins> | Philip`, shrug. |
| 23:05 | <Hixie> | i forget what it's called |
| 23:05 | <Hixie> | TextEdit2 or something |
| 23:05 | <hsivonen> | I see |
| 23:06 | <Philip`> | TabAtkins: (and about 70% use <script src>) |
| 23:06 | <TabAtkins> | I just wish emacs didn't use elisp. I can't program in elisp. |
| 23:06 | <Philip`> | (regardless of value) |
| 23:06 | <Hixie> | apparently this participant has read some press articles about html5 and likes <header> because it means she doesn't have to use <div>s with class=""es anymore |
| 23:06 | <TabAtkins> | Yay for intended consequences! |
| 23:12 | <Hixie> | she describes microdata as a simpler solution than xslt, which she called "annoying" |
| 23:12 | <TabAtkins> | Smart participant. |
| 23:13 | <Hixie> | i'm not sure whether to be offended that she likened something i worked on to XSLT, or whether to be happy she called XSLT annoying unprompted, or... |
| 23:19 | <Philip`> | I think microdata is a simpler solution than an internal combustion engine, which is big and noisy |
| 23:20 | <Philip`> | Not sure they're solutions to the same problem, though |
| 23:21 | <Hixie> | well her point was that you would use microdata instead of writing the data in xml and translating it to HTML |
| 23:21 | <Hixie> | which isn't exactly right |
| 23:21 | <Hixie> | but could be right depending on exactly what she's doing |
| 23:21 | <TabAtkins> | The use of XSLT to transform a page into the embedded data, or vice versa, is the equivalent use. |
| 23:21 | <Hixie> | like if she's exposing XML and using XSLT to get data out |
| 23:21 | <Hixie> | yeah |
| 23:21 | <Hixie> | she's actually reading the documentation, i'm shocked |
| 23:22 | <Hixie> | clearly she's not representative of normal authors :-P |
| 23:22 | <TabAtkins> | With Microdata you'd just encode things then throw a generic parser, rather than building an XSLT script to pull the info out. |
| 23:23 | <Hixie> | wooo, she actually got as far as reading about itemfor="" and actually understood it! |
| 23:23 | <TabAtkins> | Heh. |
| 23:23 | <Hixie> | she's doing vocabulary 001, and so far she's confused about the way item="" takes a type |
| 23:24 | <annodomini> | Yeah, that is kind of confusing. |
| 23:24 | <TabAtkins> | I think that confused me a bit, too. |
| 23:24 | <TabAtkins> | Heh. |
| 23:24 | <TabAtkins> | That's 3 votes against, Hixie. ^_^ |
| 23:24 | <Hixie> | yeah i think we're going to go with renaming item="" to itemtype="", make it optional, and use itemscope="" from proposal 003 |
| 23:25 | <Hixie> | also maybe we'll change itemfor="" to just referring in the other direction |
| 23:25 | <Hixie> | like sicking suggested |
| 23:25 | <Hixie> | using <ref> or something |
| 23:25 | <annodomini> | Other direction? I missed this suggestion. |
| 23:26 | <TabAtkins> | sicking thinks' it's confusing that the stranded data uses @itemfor to point to its parent, rather than the parent pointing to the stranded data. |
| 23:26 | <annodomini> | Hmm. Interesting. |
| 23:26 | <TabAtkins> | s/its parent/its Microdata parent, as opposed to its DOM parent/ |
| 23:26 | <Hixie> | instead of <div itemscope id=a></div> <span itemfor=a itemprop=name>value</span> |
| 23:26 | <Hixie> | we would have |
| 23:26 | <Hixie> | <div itemscope><itemref ref=b/></div> <span id=b itemprop=name>value</span> |
| 23:27 | <TabAtkins> | That would allow a single piece of data to be a part of multiple items. Is that intended? |
| 23:27 | <Hixie> | it would |
| 23:27 | <TabAtkins> | And would, in fact, bring back the full power of an DAG. |
| 23:27 | <Hixie> | i think that would be fine |
| 23:28 | <Hixie> | ROFL she complained about <i> being in the example |
| 23:28 | <Hixie> | "isn't that deprecated!" |
| 23:28 | <TabAtkins> | Totally not a typical author. ^_^ |
| 23:28 | <annodomini> | She sounds like she's pretty up on her standards... |
| 23:28 | <Hixie> | well except for <i> not being deprecated ever :-P |
| 23:29 | <TabAtkins> | If you can make a DAG, isn't the only thing left preventing Microdata from collapsing into RDF just the ability to make blank nodes or whatever? |
| 23:29 | <Hixie> | TabAtkins: you can make blank nodes today |
| 23:29 | <TabAtkins> | Really? |
| 23:29 | <Hixie> | TabAtkins: just don't include an "about" itemprop |
| 23:29 | <Philip`> | TabAtkins: There's also the lack of types |
| 23:29 | <TabAtkins> | Oh. |
| 23:30 | <Hixie> | yeah no per-value data types is another difference |
| 23:30 | <TabAtkins> | k. |
| 23:30 | <annodomini> | I don't think that it's bad to increase the flexibility of what you can construct, as long as that complexity is not necessary for your average usecase. |
| 23:30 | <TabAtkins> | annodomini: Yeah, I'm not saying anything against it. I just think it's funny that this syntax is *just* below being equivalent to RDFa, and yet way easier to understand. |
| 23:31 | TabAtkins | thinks that <itemref> may in fact be easier to understand after all. |
| 23:31 | <Philip`> | But maybe much more verbose for expressing certain graphs |
| 23:31 | <TabAtkins> | Philip`, maybe. I'd need to see examples. |
| 23:32 | <annodomini> | A whole new element <itemref> just for linking items to their properties? What about <link href="#b"> instead? |
| 23:32 | <TabAtkins> | Well, there's a certain benefit in maintaining the "item" prefix. |
| 23:34 | <TabAtkins> | Hixie: If you're going to make @itemtype to hold the type, then I prefer just plain @item as the scope signal. |
| 23:36 | <Hixie> | TabAtkins: people seem to be confused with the item="" attribute |
| 23:36 | <TabAtkins> | How much confusion is from @item itself, and how much from @item also acting as the type specifier? |
| 23:36 | <Hixie> | TabAtkins: and we have one data point (not enough) suggesting itemscope="" is clearer |
| 23:36 | <Hixie> | TabAtkins: well they got confused with it in both examples that had an item="" |
| 23:37 | <Hixie> | TabAtkins: so item="...id..." and item="...type..." |
| 23:37 | <Hixie> | both confused them |
| 23:37 | TabAtkins | has to go look up what item="id" means again. |
| 23:37 | <Hixie> | that's variant 002 |
| 23:37 | <Hixie> | equivalent of itemprop="about" in the spec |
| 23:38 | <Hixie> | equivalent of itemprop="itemid" in proposals 001 and 003 |
| 23:38 | <Hixie> | (we found "about" confused the heck out of people) |
| 23:38 | <Hixie> | ("itemid" so far is faring better, though we don't have much data on that) |
| 23:38 | <Hixie> | hm, this participant is being confused by having itemprop="" values that are URLs |
| 23:39 | <Hixie> | she thinks they're links to the values, rather than unique property names |
| 23:40 | <TabAtkins> | Yah, I think that's going to be inevitable some of the time. |
| 23:42 | <TabAtkins> | Hmm, I can't find itemprop=about in the spec. |
| 23:44 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#md-about |
| 23:45 | <TabAtkins> | Gotcha. That's hidden. |
| 23:45 | <TabAtkins> | And yeah, I can see how it would be confusing. |
| 23:45 | <Hixie> | everyone is making up their own property names |
| 23:46 | <Hixie> | despite us pointing them to a list of predefined vocabulary terms |
| 23:46 | <Hixie> | i guess that won't be such a problem if they just copy-paste from tutorials |
| 23:58 | TabAtkins | derives deep joy from crafting a tool that is really easy to use and useful. |
| 23:58 | <Hixie> | ooh, interesting. she prefers itemscope="" too. |
| 23:59 | <TabAtkins> | Hmm. |