| 00:13 | <Hixie> | gsnedders: let me know if there are things i should fix in html5 to get around insanity |
| 00:13 | <Hixie> | gsnedders: also, i have a feature request for you to hate me for |
| 00:13 | <Hixie> | gsnedders: is there any way i can get the web workers spec's cross-references to reference into the html5 spec? :-) |
| 00:14 | <Hixie> | gsnedders: wow, how'd you make it so quick? |
| 00:14 | <Hixie> | that's awesome! |
| 00:17 | <annevk> | I wonder if that's using the C parser rather than html5lib |
| 00:56 | <Hixie> | someone just contacted me asking if there was anywhere he could tell us how stupid he thought html5 was |
| 00:56 | Hixie | pointed him to all the usual channels (irc, forums, blog, mailing list, etc) |
| 00:59 | <jruderman> | i think html5 is this stupid: -----><---- |
| 01:01 | <Hixie> | wow, not stupid at all |
| 01:01 | <Hixie> | i'm impressed |
| 01:02 | <Hixie> | i think html5 is at least this stupid: ----->| |<-- |
| 01:02 | <franksalim> | jruderman, my line broke such that i saw that as arrows pointed in opposite directions |
| 01:02 | <Hixie> | (hopefully mine didn't line break for anyone) |
| 01:02 | <franksalim> | infinitely stupid |
| 01:02 | <Hixie> | or negatively! |
| 01:03 | <franksalim> | hey yeah |
| 01:03 | <Hixie> | and the science gets done, and you make a neat gun, for the people who are still alive. |
| 01:05 | <jcranmer> | I think the CSS debate over whether or not roc's bling is outside the scope is about as pointless as this sentence |
| 01:05 | jcranmer | looks for a way to scrub the dots off of the i's |
| 01:09 | <Hixie> | jcranmer: U+0131 :-) |
| 01:09 | <jcranmer> | in that case, |
| 01:10 | <jcranmer> | I thınk the CSS debate over whether or not roc's blıng ıs outsıde the scope of CSS ıs about as poıntless as thıs sentence |
| 01:10 | <Hixie> | :-) |
| 01:11 | <jcranmer> | I was going to do the stupid with the arrows thing, until I realized it could be interpreted in two different manners |
| 01:11 | Hixie | scrubs his morning's stupidity off html5 |
| 01:12 | <jcranmer> | --><-- could mean that there's no distance, so, ergo, it could be as stupid as nothing, or not stupid at all |
| 01:12 | <jcranmer> | unless you think that nothing is stupid |
| 01:12 | <takkaria> | this debate seems both stupid and pointless. :) |
| 01:12 | <jcranmer> | precisely |
| 01:13 | <jcranmer> | or something like that |
| 01:15 | <Hixie> | should a thread have a way to self-terminate, or should it only terminate when all of the channels connecting into it have themselves closed? |
| 01:15 | <Hixie> | if it can self-terminate, should that send an explicit unload through those channels? |
| 01:16 | <Hixie> | if it does, what about channels that the other end doesn't realise point into a worker? |
| 01:16 | <Hixie> | hmm |
| 01:19 | <jgraham> | Having threads able to self terminate sounds nice but I'm tired and should have been asleep some time ago so I'm not going to think about it now :) |
| 02:15 | <takkaria> | http://www.marcozehe.de/2008/07/16/wordpress-26-brings-a-lot-of-accessibility-improvements/ makes me sad |
| 02:15 | <takkaria> | aria introduced aria-required so that screenreaders know that an attribute is required |
| 02:15 | <takkaria> | er, text input, you know what I mean |
| 02:15 | <takkaria> | WF2 has its own required attribute |
| 02:17 | <takkaria> | and now aria-required is getting deployed widely, when instead the wf2 one could be getting deployed widely instead |
| 02:18 | <takkaria> | not worth lingering on, I guess, but it's a bit sad |
| 02:24 | <annevk> | bolt-on accessibility prolly pays better consultancy fees |
| 03:17 | <Hixie> | hmm |
| 03:17 | <Hixie> | how should we join a named worker |
| 03:18 | <Hixie> | we could have a method joinOrCreateNamedWorker(name, url) that looks for a worker named name, and if it fails to find one, creates one from URL url and gives it that name |
| 03:18 | <Hixie> | or we could have the same, but indexed on url _and_ name |
| 03:19 | <Hixie> | or we could just index on url |
| 03:19 | <Hixie> | we couldn't just have joinNamedWorker() because that would have a race condition if two threads tried to create the same shared worker at the same time |
| 03:19 | <Hixie> | hmmmmm |
| 03:22 | <othermaciej> | Hixie: in the threading context people might expect "join" to mean something else |
| 03:22 | <othermaciej> | Hixie: are named workers really necessary? |
| 03:22 | <othermaciej> | they remind me of my hate for named frame targetting |
| 03:23 | <Hixie> | one of the requests was for shared threads so that e.g. multiple gmail windows don't all try to mash the client's database at the same time |
| 03:23 | <Hixie> | i'm open to other solutions |
| 03:23 | <Hixie> | but i think it makes sense to have a single thread accessible by multiple windows that otherwise wouldn't know about each other |
| 03:24 | <Hixie> | (the namespace would definitely be per-origin) |
| 03:24 | <othermaciej> | I guess the alternative would be to have an alternate mechanism for windows from the same domain to send each other messages without directly knowing of each other |
| 03:24 | <Hixie> | then they have to negotiate a leader, which seems complicated in the face of a user closing windows |
| 03:25 | <Hixie> | i'd rather not have web authors have to implement windows-networking-style "browser elections" |
| 03:25 | <othermaciej> | I guess named threads are less bad if the namespace is separate for every origin |
| 03:25 | <othermaciej> | part of the problem with named frame/window targetting is the lack of namespace control |
| 03:26 | <Hixie> | should we make the namespace be not only per-origin but per-script-url? |
| 03:26 | <Hixie> | or is that excessive |
| 03:27 | <othermaciej> | seems excessive |
| 03:27 | <othermaciej> | one thing that concerns me is that having this as the sole mechanism for messaging between instances of a web app in different windows will lead to web apps spawning workers when they don't really need them, except for messaging |
| 03:27 | <othermaciej> | actually I guess you can use LocalStorage for messaging |
| 03:28 | <othermaciej> | (just no way to pass a MessagePort through it) |
| 03:28 | <Hixie> | are there other uses for messaging across windows? i'm happy to add some sort of same-origin, disconnected-window postMessage() mechanism |
| 03:28 | <Hixie> | but i haven't heard of any requests to do that |
| 03:28 | <othermaciej> | LocalStorage plus the change event already provides that |
| 03:28 | <Hixie> | if it's just sharing state, yeah |
| 03:29 | <Hixie> | how we design a solution depends on the problem, but i don't really know the problem on this one |
| 03:29 | <othermaciej> | updating UI state in multiple instances in response to a user action |
| 03:29 | <othermaciej> | would be one use case |
| 03:29 | <othermaciej> | but I think LocalStorage is fine for that |
| 03:29 | <Hixie> | yeah |
| 03:30 | <Hixie> | or, frankly, websocket |
| 03:30 | <Hixie> | since you'd want that to work cross-machine too |
| 03:30 | <othermaciej> | depends on the type of change |
| 03:31 | <othermaciej> | if it is a preference type setting you may want it to be per-machine |
| 03:31 | <Hixie> | true |
| 03:31 | <othermaciej> | alternately you may not want to wait for a network round trip to update locally |
| 03:31 | <othermaciej> | or you may be offline |
| 03:32 | <othermaciej> | is there a way to run a script by URL in an unnamed worker after it is already running? |
| 03:32 | <othermaciej> | (if so you only really need an API to get a worker by name and you don't have to care if it was created or retrieved) |
| 03:32 | <Hixie> | how do you mean? |
| 03:33 | <othermaciej> | well joinOrCreateNamedWorker(name, url) lets you run a new script in an existing worker |
| 03:33 | <othermaciej> | (I presume from the method signature) |
| 03:33 | <othermaciej> | but only a named one |
| 03:33 | <Hixie> | the idea was that it would either join one in progress, or fetch url, create a worker, run that script, and join that worker |
| 03:33 | <Hixie> | it wouldn't run url in the worker if it joined it |
| 03:34 | <Hixie> | (i'm looking for better names if you have any ideas) |
| 03:34 | <Hixie> | (right now i'm using createNamedWorker) |
| 03:34 | <othermaciej> | that seems like a potentially confusing design |
| 03:34 | <Hixie> | agreed |
| 03:34 | <Hixie> | not sure what is better though |
| 03:35 | <Hixie> | (btw, we might cut all this joining stuff out altogether in due course, but let's for now assume we're trying to address this use case) |
| 03:35 | <Hixie> | (that way we have a clear extension path even if we do decide to cut it from v1) |
| 03:35 | <othermaciej> | I twitch whenever you say "join" because in threading terminology, to join a thread means to block and wait for it to terminate |
| 03:36 | <Hixie> | these aren't threads, as you pointed out :-P |
| 03:36 | <Hixie> | what's a better term |
| 03:36 | <Hixie> | ? |
| 03:36 | <othermaciej> | "get" |
| 03:36 | <othermaciej> | (since you're just retrieving an ID) |
| 03:36 | <Hixie> | ok |
| 03:36 | <othermaciej> | (and it's normal for get to have "or create if needed" semantics) |
| 03:37 | <othermaciej> | (or at least not uncommon) |
| 03:37 | <Hixie> | i could call it getNamedWorker(), but then it looks weird because the two methods are createWorker() and getNamedWorker() |
| 03:38 | <Hixie> | and they are both ways to create workers |
| 03:38 | <Hixie> | (though one "gets" a worker if it can) |
| 03:38 | <othermaciej> | create always makes a new one |
| 03:38 | <othermaciej> | you could also call the other one create and not worry about it sometimes reusing |
| 03:38 | <Hixie> | (btw i was using "join" in the old tv sense of "we now join this programme, already in progress") |
| 03:39 | <Hixie> | yeah calling both create() is what my original proposal had |
| 03:39 | <othermaciej> | I think maybe there should be an object identifying a worker separate from the port which has a method to queue a script to run in the worker (by URL or source text) |
| 03:39 | <othermaciej> | then you can separate loading a script from creation |
| 03:40 | <othermaciej> | but still be able to vend the port without letting the recipient run arbitrary code in the worker |
| 03:40 | <Hixie> | that would be weird |
| 03:41 | <Hixie> | kinda like navigating a frame to a javascript: uri |
| 03:41 | <Hixie> | to make it run script |
| 03:41 | <othermaciej> | or like injecting a <script> element on a frame or calling eval() on a frame |
| 03:41 | <othermaciej> | but asynchronous of course |
| 03:41 | <Hixie> | yeah |
| 03:42 | <Hixie> | not sure we really want to go there |
| 03:42 | <othermaciej> | it just seems odd that you can only make a thread load a script when creating it |
| 03:42 | <Hixie> | just consider the script to _be_ the thread |
| 03:42 | <Hixie> | then it's not so weird |
| 03:42 | <othermaciej> | (obviously you need to at least in that case, so that it can bootstrap, but why are they tied?) |
| 03:42 | <othermaciej> | then createNamedWorker should fail if the URL doesn't match |
| 03:42 | <Hixie> | ok |
| 03:43 | <Hixie> | that makes sense |
| 03:43 | <othermaciej> | but I don't think it makes sense to say that the script *is* the thread |
| 03:43 | <othermaciej> | it's just the startup code, then the thread sits and waits for events / timers / etc |
| 03:43 | <Hixie> | well i don't say that, but that's more like how i envisage it, as opposed to a bucket you throw scripts into willy nilly |
| 03:45 | <othermaciej> | it should at least be able to load additional scripts into itself |
| 03:45 | <Hixie> | oh yes, for sure |
| 03:45 | <Hixie> | a worker can call include(url) |
| 03:45 | <Hixie> | which blocks for fetching the url and running it inline |
| 03:45 | <Hixie> | (at least, it is going to block unless someone wants it not to) |
| 03:46 | <Hixie> | (i don't really care either way, but blocking seems easiest and safe in this case) |
| 03:46 | <othermaciej> | maybe import(url) is better, since presumably it would not textually include |
| 03:46 | <Hixie> | import() it is |
| 03:46 | <Hixie> | (remind me to rename it if i end up calling it include() anyway, i haven't specced that bit yet) |
| 03:47 | <othermaciej> | sure |
| 03:53 | <Hixie> | when someone "gets" a worker, it sends an event to the worker with a port |
| 03:53 | <Hixie> | what should that even be called? |
| 03:53 | <Hixie> | (it used to be called 'join') |
| 03:55 | <Hixie> | it's the same message that gets fired when a worker is created in the first place, to give it the port for the channel back to its creator |
| 04:26 | <heycam> | Hixie, is the styling on the w3 hosted copy of the spec deliberately a bit more bland now? |
| 04:26 | <heycam> | e.g. no borders/backgrounds around idl sections, or the colourful backgrounds of the element definition sections? |
| 04:27 | <Hixie> | yeah i removed the custom style sheet because the w3c pubrules say not to add custom styles |
| 04:27 | <Hixie> | noticed it while i was doing the web workers spec |
| 04:28 | <Hixie> | i wouldn't have worried too much about it except the stylesheet was like a page long, which i assume is exactly hte kind of thing the pubrules are trying to avoid |
| 04:28 | <heycam> | it's harder to read now though |
| 04:28 | <Hixie> | use the whatwg version :-) |
| 04:28 | <heycam> | and i'm sure other specs use custom stylesheets |
| 04:28 | <Hixie> | i'm hoping the w3c style sheet will have some classes added that i can hook onto |
| 04:28 | <heycam> | the w3 version's url is easier to remember :) |
| 04:29 | <Hixie> | whatwg.org/html5 |
| 04:29 | <heycam> | ok that might be shorter |
| 04:31 | <Hixie> | it's also the first hit got "html5" on google, so in firefox you can just type "html5" in the location bar and hit enter |
| 04:32 | <Hixie> | oh actually i guess it doesn't do an i'm feeling lucky search for that term |
| 04:32 | <Hixie> | weird |
| 04:32 | <Hixie> | anyway |
| 04:32 | <Hixie> | whatwg.org/html5 |
| 04:36 | <Hixie> | bbiab |
| 04:42 | <jacobolus> | wow. what a useful shorter link. :) |
| 04:43 | <jacobolus> | my general method has been a google lucky search for 'html5' :) |
| 04:43 | <heycam> | google.com/search?q=html5&btnI=1 -- still a bit long :) |
| 04:44 | <jacobolus> | heycam: well for me, it’s just `go html5` |
| 04:44 | <heycam> | i wondered why my firefox was getting slow, and then i realised i had 3 copies of the html5 spec open in different windows |
| 04:45 | <heycam> | (plus about 40 other tabs) |
| 05:26 | <Hixie> | heycam: hah |
| 05:27 | <Hixie> | right now webkit seems the most able to handle the one-page version of the html5 spec |
| 06:20 | <MikeSmith> | Hixie: I'd really like for you to add the stylesheet back |
| 06:21 | <MikeSmith> | Hixie: as far as I cant tell, pubrules does not seems to absolutely forbid custom stylesheets |
| 06:21 | <MikeSmith> | the only thing I can find that it says is: |
| 06:21 | <MikeSmith> | "Any internal style sheets MUST be cascaded before this link; i.e., the internal style sheets MUST NOT override the W3C tech report styles." |
| 08:10 | <Hixie> | ok i added rules for the various classes html5 uses (idl, note, issue, example, warning) |
| 08:12 | <MikeSmith> | Hixie: cool, thanks |
| 08:13 | <MikeSmith> | we really should have some styles for all those things in the stock stylesheets, so I'll try to get them added |
| 08:13 | <MikeSmith> | quietly |
| 08:14 | <heycam> | MikeSmith, i quite like the style used on the actual w3c manual of style page |
| 08:14 | <heycam> | will the revisions to the TR stylesheets make them look like that? |
| 08:15 | <MikeSmith> | heycam: about the manual of style, you mean the aqua stuff with the blue bars? |
| 08:15 | <heycam> | MikeSmith, yeah |
| 08:16 | <heycam> | that, and using an ok non-default sans-serif font |
| 08:16 | <MikeSmith> | I don't know what the styles will look like because I will not be doing them |
| 08:16 | <heycam> | but yes the light black background thick dark blue top/bottom border style for the references i particularly like |
| 08:17 | <MikeSmith> | but that manual-of-style styles look pretty good to me too |
| 08:21 | <MikeSmith> | anyway, I will try to get some note/example/IDL-block styles in the WD/Rec stylesheets |
| 08:21 | <MikeSmith> | we really ought to have consistent styles for those across all published specs |
| 08:22 | <MikeSmith> | for consistency |
| 08:22 | <MikeSmith> | rather N of use reinventing N different styles for it |
| 08:23 | <MikeSmith> | I just hope it can be done quietly and quickly |
| 08:24 | <MikeSmith> | rather than, say, be opened up for wider suggestions/opinions and turning into a bikeshed discussion |
| 09:06 | <MikeSmith> | .warning { color: yellow; background: maroon; } |
| 09:06 | <MikeSmith> | interesting choice there, Hixie |
| 10:00 | heycam | thinks hixie has chosen colours to drive people to the whatwg version :) |
| 10:34 | <Lachy> | I'm looking into the queryScopedSelector proposal now, and trying to figure out the pre-parsing rules for it. http://lists.w3.org/Archives/Public/public-webapi/2008May/0058.html |
| 10:35 | <Lachy> | but it seems to be a lot more complicated that othermaciej's proposal |
| 10:36 | <Lachy> | cause I have to handle things like commas in functional pseudos: 'div:foo(x,y), >p' |
| 10:39 | <Lachy> | strings: a[title="foo, bar"], span[title="escaped \" quote \' marks"] |
| 10:42 | <Lachy> | I wonder if I just define that it uses the same grammar as selectors, except that the selector production becomes: |
| 10:42 | <Lachy> | selector : combinator? simple_selector_sequence [ combinator simple_selector_sequence ]* |
| 10:56 | <gsnedders> | Hixie: annevk was right: using the C parser (as in, lxml.html, libxml2's HTML parser) |
| 10:57 | <gsnedders> | Hixie: There are things you should fix in HTML 5, but they're needed in w3c-compat |
| 10:57 | <gsnedders> | Hixie: It should be able to create a usable version of HTML 5, as it is currently, in the w3c-compat mode |
| 10:57 | <Hixie> | send me mail or file a bug or let me know tomorrow and i'll fix them |
| 10:58 | <Hixie> | we have to make a clibhtml5 at some point |
| 10:58 | <gsnedders> | Yeah, certainly. |
| 10:58 | <gsnedders> | Philip` said on Monday last week that there was no single bottleneck now in html5lib/py |
| 10:58 | <Hixie> | did the suggestion i made scare you too much btw, or is it something you might be able to do? :-) |
| 10:58 | <gsnedders> | Hixie: Not for 1.0 :) |
| 10:59 | <Hixie> | i hope 1.1 ships soon :-D |
| 10:59 | <gsnedders> | (but there again, the criteria for 1.0's release are more or less just being able to do HTML 5 correctly :D) |
| 10:59 | <Hixie> | :-) |
| 11:00 | <gsnedders> | 1.1 will probably be other stuff that other people from the postprocessor |
| 11:00 | <gsnedders> | 1.2 is probably when I'll start adding really new stuff like that :P |
| 11:01 | <Hixie> | i hope 1.2 ships soon :-D |
| 11:01 | <gsnedders> | :D |
| 11:20 | <gsnedders> | Hixie: applicationcache is a dupe dfn |
| 11:21 | <Hixie> | no, one has a title="" of dom-applicationcache |
| 11:23 | <gsnedders> | No, that's not the bug :) |
| 11:24 | <gsnedders> | I'm doing too much whitespace normalisation now |
| 11:24 | <gsnedders> | <dfn>application cache</dfn> == <dfn>ApplicationCache</dfn> |
| 11:33 | <gsnedders> | Interesting. |
| 11:33 | <gsnedders> | the postprocessor removes any existing @class=seco |
| 11:33 | <gsnedders> | *secno |
| 11:44 | <Philip`> | gsnedders: The input stream is still a bit of a bottleneck, and I got reasonable improvements by rewriting a couple of its methods in C; but after that, it seemed like the rest of the time was spread around the entire tokeniser, so that whole thing would have to be rewritten in C |
| 11:45 | <gsnedders> | Then do so! :P |
| 11:45 | <Hixie> | nn |
| 11:45 | <Philip`> | (The improvement from writing the input stream in C is probably too low to be worth the cost of being a binary module) |
| 11:45 | <gsnedders> | Hixie: night |
| 11:46 | <Philip`> | gsnedders: It'd probably be most sensible to hook in Hubbub, and maybe try feeding its tokeniser output into the Python tree builders |
| 11:48 | <gsnedders> | hmm, I want some xpath statement like //*[contains(., '[DATE')], but one that doesn't return all ancestors too |
| 11:55 | <gsnedders> | /text()[contains(., '[DATE')]/.. |
| 11:57 | <Philip`> | You should use //*[foo()] where foo is a user-defined function that does what you want |
| 11:58 | Philip` | wonders if any XPath implementations actually support user-defined functions |
| 11:58 | <gsnedders> | Is that not XPath 2? |
| 11:59 | <gsnedders> | No, it is allowed in XPath 1 |
| 11:59 | gsnedders | shrugs |
| 12:00 | <gsnedders> | /text()[contains(., '[DATE')]/.. is what the above should be |
| 12:00 | <gsnedders> | wait, //text()[contains(., '[DATE')]/.. |
| 12:00 | <gsnedders> | Duh. the first / is eaten by IRC. |
| 12:00 | gsnedders | headdesks |
| 12:04 | <gDashiva> | gsnedders: So your problem is solved then |
| 12:04 | <gsnedders> | sure. |
| 12:04 | <gsnedders> | :P |
| 12:11 | <gsnedders> | (it's odd that this is actually quicker using xpath) |
| 12:12 | <gsnedders> | aim for today: get HTML 5 processed in under 3s |
| 12:25 | <MikeSmith> | gsnedders: odd that it's quicker than what? |
| 12:25 | <MikeSmith> | btw, you using lxml.etree.XPath() ? |
| 12:26 | <gsnedders> | MikeSmith: manually iterating and doing it all in Python, which is normally quicker |
| 12:26 | <gsnedders> | MikeSmith: yeah |
| 12:29 | <MikeSmith> | gsnedders: what's this tool you been working on? what's it do? |
| 12:29 | <gsnedders> | MikeSmith: The spec-gen? Basically the same as the CSS WG's Postprocessor |
| 12:29 | <MikeSmith> | ah cool |
| 12:29 | <MikeSmith> | that will be great to have |
| 12:30 | <takkaria> | gsnedders: so you're using libxml2's html parser at the moment for it? |
| 12:30 | <gsnedders> | (half the point is just so people like me, non W3C members, can access it) |
| 12:31 | <gsnedders> | takkaria: By default it uses html5lib, but it can also use that or it's XML parser |
| 12:31 | <gsnedders> | s/'// |
| 12:31 | <takkaria> | right |
| 12:32 | <MikeSmith> | would be great to have a python interface to hubbub, through lxml or however |
| 12:33 | <MikeSmith> | takkaria: would be cool to have simple command-line utility built from hubbub |
| 12:33 | <MikeSmith> | that is, like the parse.py thing for html5lib |
| 12:39 | <takkaria> | the idea of feeding hubbub's tokeniser through lxml's treebuilder seems to be a good one for speeding up html5lib |
| 12:42 | <MikeSmith> | takkaria: yeah |
| 13:59 | <hdh> | Hixie: in Link type "icon", "either width string or height string start with" should read "starts" |
| 14:03 | <Philip`> | There's about a million other places where the spec has grammar issues like that |
| 14:53 | <gsnedders> | Hixie ought to learn English. |
| 15:16 | <gsnedders> | "If url doesn't match the <URI-reference> production, even after the above changes are made to the ABNF definitions, then parsing the URL fails with an error." |
| 15:17 | <gsnedders> | In what cases can it fail? |
| 15:43 | mpt | wonders what one is supposed to do to get HTML 5 sectioning elements working in IE |
| 15:43 | <Philip`> | mpt: <script>document.createElement('section')</script> should make it parse better |
| 15:44 | <Philip`> | (if you run that script some place before you use a <section> element) |
| 15:45 | <mpt> | Philip`, does that need to be done for each <section> element in the page? |
| 15:45 | <Philip`> | mpt: No - it just needs to be done once, and then IE's parser will recognise that element as being an XML-like element for the rest of the page |
| 15:45 | <mpt> | ah, neat |
| 15:46 | <mpt> | I guess the same applies to <aside> |
| 15:46 | <Philip`> | (where "XML-like" means you can do <section/> etc) |
| 15:46 | <Philip`> | Yep |
| 15:46 | <mpt> | I was expecting to find tricks like this on the wiki, but I couldn't find any authoring info there |
| 15:46 | <smedero> | There's some discussion around that method on Sam Ruby's blog: http://www.intertwingly.net/blog/2008/01/22/Best-Standards-Support |
| 15:47 | <smedero> | (sorta, scattered across the comments) |
| 15:47 | <smedero> | ahh right, and here: http://ejohn.org/blog/html5-shiv/ |
| 15:48 | <mpt> | Anyone mind if I create a "For Web authors" section on the wiki that contains only that to start with? :-) |
| 15:49 | <Philip`> | That sounds quite reasonable to me |
| 15:50 | <Philip`> | as long as you note that it's an evil hack that takes advantage of IE's insanity ;-) |
| 15:57 | <mpt> | done |
| 15:59 | <mpt> | thanks for the tip Philip` |
| 16:03 | <gsnedders> | Can the postprocessor, _PLEASE_ be sane |
| 16:03 | <Philip`> | Thank Microsoft for implementing such a useful and obvious feature |
| 16:05 | <gsnedders> | "<!--logo-->Foo" results in the obvious output of <!--begin-logo-->\n\n <p><a href="http://www.w3.org/"><img alt=W3C height=48\n src="http://www.w3.org/Icons/w3c_home"; width=72></a> <!--end-logo-->\n\n <p>Foo |
| 16:08 | gsnedders | refuses to do the crazy after stuff |
| 16:12 | gsnedders | finds a bug in the docs |
| 16:16 | <tusho> | What would be an appropriate tag for "the main page content"? |
| 16:16 | <tusho> | You have <header>, <???>, <footer> |
| 16:21 | <smedero> | <section> or <article> would be appropriate depending on the type of content. |
| 16:21 | <tusho> | smedero: Multiple articles, though. (A recent posts page). |
| 16:22 | <tusho> | So: header being the generic starting cruft, ??? being the thing containing each <article>, then footer |
| 16:22 | <tusho> | <section id="content">, I suppose. |
| 19:03 | <hdh> | I'm using <body><header/> (<article><header/>...<footer/></article>)+ <footer/></body> |
| 19:32 | <gsnedders> | ERGH. |
| 19:32 | <gsnedders> | The docs really SUCK. |
| 19:32 | <gsnedders> | "If there is a H2 subheading under the H1 that gives the spec's status, the [STATUS] variable will be initialized from that, otherwise it will default to WD." |
| 19:33 | <gsnedders> | Actually, it isn't initalized from there, and it defaults to ED. |
| 19:35 | <gsnedders> | [LONGSTATUS] is completely and utterly undocumented |
| 19:41 | <gsnedders> | ERGH. |
| 19:42 | <gsnedders> | http://www.w3.org/StyleSheets/TR/W3C-ED gets changed per the status by complete magic |
| 19:43 | gsnedders | stabs stabs stabs |
| 19:45 | Philip` | gets 13 different outputs from a single function that does a few floating-point calculations, between various compilers and compiler flags |
| 19:46 | <Philip`> | (which makes me unhappy since I want cross-platform deterministic simulations) |
| 19:46 | <Lachy> | gsnedders, the status gets acquired from the This Version link: <dd><a href="[VERSION]/">http://www.w3.org/TR/[YEAR]/ED-selectors-api-[CDATE]/</a></dd>; |
| 19:46 | <gsnedders> | Lachy: Yeah, I've reverse engineered that now |
| 19:47 | <Lachy> | I reverse engineered that once before when I needed to actually change it once. |
| 19:55 | <gsnedders> | Actually, that isn't the behaviour |
| 19:55 | <gsnedders> | It just finds the first http://www.w3.org/TR/[YEAR]xxx- |
| 20:03 | <Lachy> | gsnedders, could you make your spec generator generate all that boiler plate markup from a simpler syntax? |
| 20:04 | <gsnedders> | Lachy: how much is "all" |
| 20:04 | <Lachy> | everything in the <dl> near the top that includes This Version, Previous Versions, Editors, etc. |
| 20:06 | <gsnedders> | Lachy: What do I put in editors, previous versions, latest version? What URLs do I use for this version? |
| 20:06 | <gsnedders> | Oh lovely, "[Sorry, the postprocessor doesn't yet have the boilerplate text for this status]" |
| 20:08 | <Lachy> | gsnedders, you would need the author to provide a list of URLs, and then you just generate the link and dl markup |
| 20:09 | <gsnedders> | Lachy: It'd be easier just to have something to cut out the duplication of the URLs |
| 20:09 | <gsnedders> | and that'd cut it down quite a lot |
| 20:09 | <Lachy> | so a comment at the top that was formatted like this: |
| 20:09 | <gsnedders> | I know what you mean |
| 20:09 | <Lachy> | Selectors API |
| 20:09 | <Lachy> | WD |
| 20:09 | <Lachy> | This Version: |
| 20:09 | <Lachy> | http://www.w3.org/TR/2008/ED-selectors-api-20080717/ |
| 20:09 | <Lachy> | Latest Version: |
| 20:09 | <Lachy> | http://www.w3.org/TR/selectors-api/ |
| 20:09 | <Lachy> | Previous Versions: |
| 20:10 | <Lachy> | http://www.w3.org/TR/2007/WD-selectors-api-20071221/ |
| 20:10 | <Lachy> | http://www.w3.org/TR/2007/WD-selectors-api-20071019/ |
| 20:10 | <Lachy> | http://www.w3.org/TR/2006/WD-selectors-api-20060926/ |
| 20:10 | <Lachy> | http://www.w3.org/TR/2006/WD-selectors-api-20060525/ |
| 20:10 | <Lachy> | Editors: |
| 20:10 | <Lachy> | Editor Name1 (Affiliation) <user⊙ec> |
| 20:10 | <Lachy> | Editor Name2 (Affiliation) <user⊙ec> |
| 20:10 | <gsnedders> | Some specs don't have that format though |
| 20:11 | <Lachy> | which specs? |
| 20:11 | <gsnedders> | I'd rather have something like <!--begin-link-->http://www.w3.org/TR/2008/ED-selectors-api-20080717/<!--end-link-->; that got converted into a link to http://www.w3.org/TR/2008/ED-selectors-api-20080717/ with that as its content |
| 20:11 | <gsnedders> | css3-namespace, for example |
| 20:11 | <Lachy> | yes it does |
| 20:11 | <gsnedders> | <dd><a href="http://annevankesteren.nl/contact">Anne van Kesteren</a>, Opera Software ASA</dd> |
| 20:11 | <gsnedders> | That doesn't look like that format to me :) |
| 20:12 | <Lachy> | oh, yeah, I forgot the links to the home pages. |
| 20:12 | <Lachy> | but the affiliation and email addresses are optional. |
| 20:12 | <Lachy> | that's not a problem |
| 20:13 | <gsnedders> | I just think having it all as a comment doesn't help that much more than just something to create a link |
| 20:13 | <gsnedders> | Because that cuts down most of the excess stuff in the header |
| 20:13 | <Lachy> | I just want a way to reduce as much markup as possible |
| 20:13 | <gsnedders> | Do you really touch the top that often? :P |
| 20:14 | <Lachy> | no, but it should be easy to edit when I do. |
| 20:14 | <gsnedders> | Lachy: And the current difficulty is from what? The duplication of URLs? |
| 20:15 | <Lachy> | yeah, the duplcation is a problem cause when I copy and paste to add another one, it's easy to forget to change one of the links |
| 20:16 | <gsnedders> | Yeah, and my proposal gets rid of that duplication |
| 20:16 | <Lachy> | and also creating a new spec requires too much editing |
| 20:17 | <Lachy> | marking up editor names is the most complicated for creating a spec |
| 20:19 | <Lachy> | also, the duplication in the <title> and <h1> |
| 20:19 | <gsnedders> | I'm not sure how simpler we can make editor names, though |
| 20:19 | <gsnedders> | I could add [TITLE] for that |
| 20:23 | <Lachy> | ok |
| 20:28 | <gsnedders> | Hmm, it must be more complex than I thought |
| 20:28 | <gsnedders> | http://dev.w3.org/cvsweb/csswg/cssom/Overview.src.html?rev=1.67&content-type=text/x-cvsweb-markup |
| 20:29 | <gsnedders> | that would result in [STATUS] == REC if I were right |
| 20:31 | <Lachy> | gsnedders, why? |
| 20:32 | <gsnedders> | Lachy: first http://www.w3.org/TR/[YEAR]/xx- link |
| 20:32 | <Lachy> | the first such link is http://www.w3.org/TR/[YEAR]/WD-cssom-[CDATE]/ |
| 20:33 | <gsnedders> | that's in a comment, and is certainly ignored |
| 20:34 | <gsnedders> | [STATUS] == ED for that document, the default |
| 23:06 | mpt | is now unpleasantly surprised that <aside> doesn't work in Firefox 2 |
| 23:07 | <Philip`> | Upgrade to FF3 :-) |
| 23:07 | <mpt> | I have, but ~11% of our page hits come from FF2 |
| 23:09 | <Philip`> | Wait a few months |
| 23:09 | <Philip`> | and then everyone else should have upgraded |
| 23:10 | <Dashiva> | Not unless it gets backported to fifteen million linux distros |
| 23:11 | <Philip`> | Fourteen point many-nines of those Linux distros have no users, so they don't matter |
| 23:12 | <Philip`> | Uh |
| 23:12 | <Philip`> | Fourteen point many-nines millions |
| 23:12 | <Philip`> | and Ubuntu already has FF3 and who cares about anything else |
| 23:12 | <mpt> | So you're saying I should buy Alexander Sack lunch tomorrow, then? :-) |
| 23:13 | <Dashiva> | Philip`: Ubuntu newer than some version, yes |
| 23:13 | <mpt> | (for shipping Ubuntu 8.04 with FF3 beta instead of FF2) |
| 23:14 | Philip` | sees that Gentoo has mozilla-firefox-3.0 and mozilla-firefox-bin-3.0, but not marked as stable yet :-( |
| 23:15 | <mpt> | 63% of our page hits are from people using Linux, but still FF2 is at 12% |
| 23:17 | <mpt> | <div class="aside"> is looking tempting ;-) |
| 23:30 | <gsnedders> | Philip`: Well get a better distro yourself :P |
| 23:41 | <Lachy> | JohnResig, yt? |
| 23:48 | <gsnedders> | Yay! |
| 23:48 | <gsnedders> | I've made sense of the status detection done by the spec-gen, at last |
| 23:49 | <Hixie> | mpt: <div class="aside"> is what i would recommend for now anyway |
| 23:49 | <gsnedders> | It stops looking at "latest version" |
| 23:49 | <mpt> | ok |