00:04
<zcorpan_>
nn
00:20
<smaug_>
hmm, I guess I need to look at how websocket protocol has changed (again)
00:22
<smaug_>
looks pretty same to v76
00:22
<smaug_>
at least as ugly as v76
00:23
<Hixie>
yeah only minor changes
00:24
<smaug_>
ah, the API has changed too
00:24
<smaug_>
there is now protocols[]
00:24
<Hixie>
yeah
00:25
<Hixie>
i mailed wellington about it
00:25
<Hixie>
wasn't sure who else to mail
00:25
<smaug_>
I wonder what the use case is for that.
00:26
<smaug_>
Hixie: well, if you could cc me
00:27
<Hixie>
the protocols[] thing was mentioned on the hybi list
00:28
<Hixie>
basically the use case was to let someone who implements several protocols in the JS but doesn't know what the server implements simply give the list to the server
00:28
<Hixie>
and let the server pick
00:29
<smaug_>
not sure that is a good use case
00:29
<Hixie>
yeah i wasn't hugely convinced either, but it seemed easy enough to support.
00:31
<Hixie>
i recommend posting on the hybi thread if you want the protocol changed... i think it was http://www.ietf.org/mail-archive/web/hybi/current/msg02250.html
00:34
<smaug_>
oh, it was somewhere in that thread
00:38
<Hixie>
(i didn't see anyone say it was a bad idea, which is why i went with it)
00:59
<JonathanNeal>
well, just in case
01:00
<JonathanNeal>
Hixie, the link was http://sandbox.thewikies.com/html-templates/outliner.php?url=http://html5doctor.com/
01:00
<JonathanNeal>
And outliner I'm working on.
01:00
<Hixie>
cool
01:00
<Hixie>
sorry, missed it earlier
01:01
<Hixie>
it seems to not handle ln.hixie.ch right
01:01
<Hixie>
unless i'm missing something
01:04
<Hixie>
JonathanNeal: it seemed to do better than i expected on the spec itself, but then it has all kinds of weird stuff at the bottom (http://sandbox.thewikies.com/html-templates/outliner.php?url=http://www.whatwg.org/specs/web-apps/current-work/complete.html)
01:04
<Hixie>
oh, wait, it didn't get any of the numbering right
01:04
<Hixie>
all the numbers are the ones from the spec itself
01:04
<Hixie>
still has some way to go it seems :-)
01:05
<JonathanNeal>
Obviously, still waiting for it to load that link for me.
01:05
<JonathanNeal>
Oh that's because you don't use any sections.
01:05
<JonathanNeal>
Got it.
01:05
<Hixie>
yeah it's all implied sections
01:06
<JonathanNeal>
Not until you get to Images.
01:06
<JonathanNeal>
All right, I'll work on that.
01:06
<JonathanNeal>
That shouldn't be so so hard.
01:08
<Hixie>
there's also some weirdness... is your parser treating &lt;h1&gt; as <h1> or something?
02:28
<bga_>
hi :)
03:51
<roc>
anyone here actually written an application that uses the HTML5 offline application cache?
03:55
<roc>
failing that, anyone know of any examples of Web apps using the HTML5 offline application cache?
04:01
<othermaciej>
do you mean "real" ones or would a sample do?
04:01
<othermaciej>
this is a demo example: http://webkit.org/demos/calendar/Calendar.html
04:01
<othermaciej>
I am also told it is widely used for real in mobile-targeted Web apps, but I have no concrete examples handy
04:02
<roc>
I was looking for a real one, but thanks
04:28
<boblet>
does anyone know what became of allowing a year in @datetime?
07:32
<Hixie>
http://lists.w3.org/Archives/Public/public-html/2010May/0095.html
07:33
<Hixie>
"Once you've done all that, you are going to be looking at something very similar to TTML" seems to not have turned out to be true
07:33
<Hixie>
(websrt does all but 1 of his bullet points, if i'm not mistaken)
07:34
<Hixie>
(actually 2, but the second is something we could add pretty easily)
07:43
<boblet>
MikeSmith, Hixie: re: mark element, is my use of it to wrap section permalinks when the user hovers over section titles in http://oli.jp/2009/html5-faq/ incorrect? Lachy thought I was stretching the meaning too much, I’m on the fence. 2nd opinion?
07:44
<Hixie>
i don't understand why <mark> would even remotely be appropriate there, but maybe i'm lacking imagination... what argument would you use to defend it? :-)
07:45
<abarth>
Hixie: do you have a couple minutes to talk about URL parsing?
07:45
<boblet>
har! it’s text that isn’t important, is highlighted for reference purposes, and is only relevant when you want a chapter permalink to copy
07:45
<zdenekkostal>
boblet: Nice page, but using mark is like use styled paragraphs instead of headlines :)
07:46
<MikeSmith>
boblet: I'm not much help here -- I don't know what the use cases are for mark other than the one of highlighting words in a page that are search terms you used when looking for that page
07:46
<boblet>
Lachy suggested it should be informationally relevant, not relevant to current action
07:46
<Hixie>
abarth: sure
07:46
<abarth>
i was thinking about getting started on it
07:47
<Hixie>
boblet: "highlighted for reference purposes" seems a bit of a stretch since your default style is to hide it :-)
07:47
<MikeSmith>
boblet: so I guess I thought the general purpose of mark is to bring the user's attention to some particularly relevant text that they would otherwise have to look for manually
07:47
<abarth>
now that the parser work is winding down, i should get back to URL stuff
07:47
<abarth>
Hixie: you mentioned you had strong feelings about how the spec should be structured
07:47
<Hixie>
abarth: yeah
07:48
<Hixie>
we have several options here
07:48
<MikeSmith>
boblet: so I guess using it to highlight permalink markers kinda seems like overkill to me
07:48
<boblet>
Hixie: well, it’s highlighted for reference when the action of getting the permalink is relevant :)
07:48
<boblet>
ok, seems I was a little too creative in reading the spec. thanks :)
07:48
<micheil>
that reminds me.. I need to setup that daily cron job on my server to push the latest spec revisions to that github mirror
07:49
<Hixie>
abarth: that is, several somewhat orthogonal axes. Rely on or be completely independent from the IRI/URI specs; and define things declaratively or imperatively, being two main ones.
07:49
<Hixie>
abarth: i think we're best off doing an independent imperative-style spec for this.
07:49
<abarth>
you don't think we'll run into less trouble later if we output something that the URI spec can parse?
07:49
<Hixie>
abarth: maybe with a (normative) appendix that defines the semantics in terms of an IRI
07:49
<Hixie>
abarth: the uri spec doesn't define parsing
07:50
<abarth>
oh, i thought there was a regular expression in the appendix that did the parsing
07:50
<Hixie>
abarth: but assuming you mean something the uri spec thinks is valid, then no, because the whole problem is that there are invalid uris we need to handle that have no valid mapping.
07:50
<abarth>
i see
07:50
<boblet>
zdenekkostal: btw I’m not sure I understand your metaphor — do you mean this usage (in which case what is the equivalent of headlines) or any use of mark?
07:50
<abarth>
one annoying thing is that the parsing depends on whether the UA understands a given scheme
07:51
<Hixie>
abarth: i basically see no value in defining things the way the spec used to have it, or the way [webaddresses] had it, where the implementor has to do some work to pass the string to some other function to do more work
07:51
<Hixie>
abarth: i think we're better off just defining the parsing once and being done with it
07:51
<abarth>
ok
07:51
<Hixie>
abarth: (we can mostly defer to iri/uri for validity definitions, though)
07:51
<abarth>
we're going to run into trouble later on, but we can deal with that then
07:51
<boblet>
MikeSmith: btw, sorry not to catch up this week — it became 3 days of meetings. also can you put a flowchart aside for Daniel? Also Kyle has a little something for you to read too
07:52
<abarth>
there are two mostly independent algorithms:
07:52
<abarth>
parsing
07:52
<abarth>
cannonicalization
07:52
<Hixie>
abarth: re the annoying thing, i think our best bet is to have hard-coded definitions of the special behaviour for the important schemes, and require generic handling of all the remaining schemes
07:52
<Hixie>
abarth: there are three, i think - parsing, resolving, and canonicalisation/serialisation
07:52
<abarth>
ok, that includes default ports and whether the scheme uses the authority-style
07:52
<abarth>
oh, yeah resolving
07:53
<abarth>
i haven't gotten to that one
07:53
<Hixie>
the "authority-style" thing is mostly gone in the more recent specs, iirc
07:53
jgraham
forms the URL-spec cheerleaders club to motivate our heroic editor and entertain the crowds
07:53
<abarth>
well, foo:bar
07:53
<abarth>
becomes foo://bar
07:53
<abarth>
if foo is a "standard URL scheme"
07:53
<Hixie>
yeah iirc the new uri specs have something generic to say about that, i forget what exactly
07:53
<abarth>
in GURL parlance
07:53
<Hixie>
anyway
07:53
<abarth>
but yeah
07:54
<Hixie>
my point is i think we can draw a line in the sand and make it Just Work in the future for future schemes, at least for unknown ones
07:54
<Hixie>
and define what's known
07:54
<Hixie>
not sure what to do about ports
07:54
<Hixie>
we should check what the official specs say
07:54
<abarth>
default ports can cannonicalized away
07:54
<Hixie>
since they claim to be knowledge-agnostic nowadays iirc
07:54
<abarth>
for known schemes
07:54
<abarth>
s/can/get/
07:55
<Hixie>
abarth: personally all i need is something to reference for the two red boxes in http://www.whatwg.org/specs/web-apps/current-work/complete.html#urls
07:56
<boblet>
Also what’s the situation with no year-only @datetime? I guess it’s on purpose, but I wonder why given year-month and year-week pattern
07:56
<abarth>
you need to understand default ports to do security origin comparisons correctly
07:56
<Hixie>
abarth: ideally also we'd get a slightly less mathematical definition of "absolute url"
07:57
<Hixie>
abarth: yeah, we might just be stuck with the knowledge thing
07:57
<Hixie>
boblet: @datetime?
07:57
<Hixie>
boblet: you mean <ins datetime="">?
07:57
<boblet>
Hixie: sorry, <time datetime="">
07:57
<abarth>
Hixie: in webkit the security origin class has its own table of default ports that separate from the one in the URL library
07:57
<abarth>
which is kind of goofy
07:57
<Hixie>
abarth: yeah that's pretty special
07:58
<abarth>
ok, i think i understand your requirements
07:58
<abarth>
i'll probably start a github project and start writing something next week
07:59
<Hixie>
boblet: the point of <time> is two-fold, (1) to make it easier to import times into a calendar, e.g. via microdata, and (2) make styling locale-specific
07:59
<zdenekkostal>
boblet: When I think about it, using <mark> isn't so bad in this context... really, there is no equivalent for headlines (via my metaphor). My apologize :)
07:59
<Hixie>
boblet: neither of these makes much sense for years
08:00
<boblet>
hixie: cool, thanks for explaining
08:01
<boblet>
zdenekkostal: I thought it was a nice creative use too, but it seems I should just be using the <a> that’s there, and wrapping it in <mark> is stretching <mark>’s meaning a little far :) it’s fun to think about how new elements can be used though huh
08:30
<zcorpan_>
Hixie: maybe reposition the captions again when the controls stop showing?
08:30
<Hixie>
i thought of that but figured it'd be better to minimise the jumping around
08:30
<Hixie>
they'll go away soon enough anyway
08:30
<zcorpan_>
what if the next cue wants to position the caption where the old caption is now?
08:31
<Hixie>
well then i guess you get a cascade of problems until such time as it settles down
08:32
<zcorpan_>
maybe it's not a problem in practice
08:32
<Hixie>
probably not in most cases
08:32
<Hixie>
there are pathological cases where it'd be an issue, but they'll be rare
08:33
<Hixie>
and you can always just toggle the captions on-off if you really want to reset it
08:33
<Hixie>
(assuming you can do so without the controls showing!)
08:33
<zcorpan_>
maybe reposition the existing captions when the next one gets showed, if they're repositioned and the controls are no longer visible
08:33
<Hixie>
imho we should minimise any repositioning
08:34
<zcorpan_>
that would do nothing in the normal case but still fix the scenario above
08:36
<Hixie>
imagine a UA that shows control at the top left
08:37
<Hixie>
and a video that has titles at the bottom except for one title at the top left, which happens to be showing when the controls show, and which are on the screen for a long time
08:38
<zcorpan_>
yeah, it'd jump around when it's not necessary too
08:38
<Hixie>
technically a UA could reset the titles whenever it wants, and just claim that it was toggling the captions based on a psychic user interface
08:38
<Hixie>
but i'd rather not make that explicit
08:38
<Hixie>
since it'd encourage making the titles jump around a lot more than they need to
08:40
<zcorpan_>
i wonder how we solve author-provided controls
08:41
<zcorpan_>
should the author be able to insert and remove a css box and cause the captions to reposition?
08:42
<zcorpan_>
if not i expect authors are going to reimplement captions with script to support this
08:42
<Hixie>
author captions are often not overlaid (e.g. youtube isn't)
08:43
<zcorpan_>
the video mozilla showed on the firefox page when firefox 3.5 was released had captions that moved when the controls showed
08:45
<Hixie>
uri?
08:47
<hsivonen>
it's so sad that people fall for stuff like http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027273.html
08:47
<hsivonen>
(the attack described in that email, that is)
08:49
<Hixie>
the javascript: thing?
08:49
<zcorpan_>
Hixie: can't find it anymore
08:52
<MikeSmith>
there are users who fall for simple phishing e-mails along the lines of "Your credit card number may have been used without your authorization! Go to the following page and type in your name, credit-card number, expiration date, and PIN number to get a report about any authorized uses of your credit-card information."
08:53
<MikeSmith>
Hixie: patch for adding IDs to index for event-handler attributes - http://www.w3.org/Bugs/Public/attachment.cgi?id=892
08:53
<Hixie>
"ix"?
08:54
<MikeSmith>
Hixie: ix = index
08:54
<MikeSmith>
I'm happy to change it something else
08:54
<MikeSmith>
or of course feel to free to change it to anything you want
08:54
<hsivonen>
Hixie: the thing that tells you to type letters with modifiers keys
08:55
<Hixie>
hsivonen: ah, yeah
08:57
<foolip>
Hixie, was there some good reason for making captions the default kind for <track>?
08:57
<foolip>
it seems to me that it's more likely that most things will be subtitles, i.e. not including cues for HoH
08:59
<Hixie>
foolip: i was trying to appease the a11y camp
09:01
<zcorpan_>
the default should be the most common use, or most uses will be mislabeled (since it works anyway, people will omit kind="")
09:02
<foolip>
I only remember seeing you an Silvia discussing it, I haven't seen it discussed on the HTML a11y TF mailing list.
09:02
<Hixie>
foolip: it was a pre-emptive attempt
09:02
<Hixie>
MikeSmith: checked in
09:03
<foolip>
What would you call timed text in the original language that doesn't include HoH cues? Is that subtitles or captions?
09:03
<foolip>
I'm interested since that's the kind of timed text I write most and want to label it appropriately.
09:04
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/complete.html#attr-track-kind defines "subtitles" vs "captions" in a way that I think answers your question
09:07
<foolip>
it's not translated, so it isn't subtitles. it also isn't suitable either when the audio is muted or for the HoH since it doesn't include things like [door rings], so it's not captions.
09:08
<foolip>
(but disregarding the spec, I would call it subtitles)
09:08
<foolip>
anyway...
09:08
<foolip>
suggest making subtitles the default, but we'll see what others think.
09:14
<zcorpan_>
hmm, firefox still has websocket.URL
09:15
<Hixie>
man, the .url/.URL situation is a cluster...uh, is a mess
09:15
<Hixie>
foolip: please send mail and/or file a bug :-)
09:15
<foolip>
I will
09:15
<Hixie>
foolip: also mention that subtitles says translation-only, i'll fix that
09:16
<foolip>
sure
09:16
<foolip>
huh, why hasn't your long email hit the archives yet?
09:16
<Hixie>
the archives are weird
09:16
<Hixie>
sometimes they seem to be hours behind
09:16
<Hixie>
i dunno why
09:16
<foolip>
oh well
09:16
<Hixie>
other times they're up to the second
09:16
<Hixie>
anyway, bed time for me
09:17
<Hixie>
tomorrow i start down the processing-model IMAP folder
09:17
<Hixie>
which has 1,115 e-mails at the moment!
09:17
<foolip>
best of luck!
09:18
<Hixie>
the chart i use has a simplistic estimate -- i just draw a line from the first point to the last point and if it goes down, i predict where it'll hit the x-axis
09:18
<zcorpan_>
oh, no i was mistesting it
09:18
<Hixie>
i said that we'd hit CR (the next time we'll be at 0 e-mails) in 2012
09:18
<Hixie>
the current estimate is "Estimated date for last e-mail based on the data above: 2012-10-01"
09:19
<Hixie>
it took about 10 months to get from 1692 e-mails to zero last time i was at 1692
09:20
<Hixie>
so that would predict Q2 2011
09:21
<Hixie>
i have a wild objective for this quarter of reaching about 50 e-mails by the EOQ, i.e. end of September.
09:21
Hixie
isn't optimistic
09:27
<MikeSmith>
Hixie: thanks for the index fix .. I find now there were two typos in the patch I sent -- here's a follow-up: http://www.w3.org/Bugs/Public/attachment.cgi?id=893
09:27
<jgraham>
AryehGregor: (random aside: I think what SteveF's data indicates is that screenreader's assumption that filenames are meaningful is horribly broken)
09:27
<jgraham>
s/'s/s'/
09:28
<jgraham>
Is that correction right?
09:30
<hsivonen>
argh. lists.w3.org search is "undergoing some routine maintenance" :-(
09:31
<jgraham>
Is that like routine surgery i.e. involving a non-negligible possibility of death
09:35
<MikeSmith>
hsivonen: search is probably broken because I noticed yesterday that the Archived-at message-ID dereferencer thingy wasn't working, so I asked systems team to fix it, and I think they might be doing some more serious fixing on it so that it won't break again
09:36
<hsivonen>
MikeSmith: ok
09:36
<hsivonen>
I managed to locate the email I was looking for without search
09:36
<MikeSmith>
ok
09:37
<MikeSmith>
fyi, I just checked and status note says "will be unavail probably until friday midday" (midday US/East)
09:38
<jgraham>
Oh jesus
09:38
<jgraham>
I should unsubscibe from HyBi
09:38
<jgraham>
It makes me want to cry
09:39
<jgraham>
Someone is pretending that the "amateur programming" requirement implies "weak-minded" or "IQ less than 90"
09:39
<jgraham>
To discredit it
09:44
<Peter`>
Is there a rationale somewhere about why HTML doesn't accept ".1" as a valid floating point, whereas CSS and JavaScript do?
09:44
<Peter`>
it's rather hard to search for
09:46
<zcorpan_>
jgraham: i'm considering unsubscribing as well
09:47
<MikeSmith>
jgraham: yeah, there are some real sweethearts on the hybi list
09:48
<MikeSmith>
the comment "Do we have an issue open about amateur protocol designers and amateur editors? amateur chairs?" was a real gem too
09:49
<jgraham>
If I was running the list you would be thrown off for messages like that. But I am not, so...
09:50
<hsivonen>
Remember to object before the polls close!
09:51
<jgraham>
hsivonen: Which polls?
09:51
<hsivonen>
jgraham: the versioning poll
09:51
<jgraham>
Oh man.
09:51
<jgraham>
I didn't even notice that
09:51
<hsivonen>
jgraham: the other one is less important, but feel free to object to the ascii-ref, too
09:52
<jgraham>
I was hoping that no one would reply to the ascii ref poll to highlight what an enormous waste of everyone's time it is
09:52
<jgraham>
But they did :(
09:53
<foolip>
where's the versioning poll?
09:54
<foolip>
I've missed that
09:54
<hsivonen>
foolip: http://www.w3.org/2002/09/wbs/40318/issue-101-objection-poll/results
09:54
<hsivonen>
foolip: doh. sorry
09:54
<hsivonen>
foolip: http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/
09:54
<foolip>
hsivonen, thanks
10:01
<foolip>
I like Grant Simpson's argument about making it easier for the electronic archaeologist
10:02
<jgraham>
In what sense "like"?
10:02
<foolip>
Eh, ironically but not mockingly?
10:03
<jgraham>
Ah
10:03
<foolip>
I don't doubt it's true, but not terribly important
10:03
<foolip>
OK, let's object a bit then... perhaps strongly?
10:03
<jgraham>
It seems to me that just looking markup features present in each version of HTML would be at least as accurate
10:04
<foolip>
true
10:04
<foolip>
or the date when archive.org first archived it :)
10:04
<jgraham>
Possibly moreso because there will be an uptick when browsers start supporting a given construct, so you can date to browser revisions not just spec revisions
10:05
<Workshiva>
jgraham: I think it's better that people reply and explicitly highlight what a waste of time it is, rather than implicitly
10:06
<jgraham>
Workshiva: It would only have been worthwhile if it got literally zero replies. Or, more likely, just one, from Julian
10:06
<jgraham>
SO it was a longshot :)
10:06
<zcorpan_>
the electronic archive will go away, all that's left after 1000 years is a copy of the spec that a microsoft employee printed and put in a black box
10:07
<hsivonen>
Microsoft should get stone-carving printers, just in case
10:07
<Workshiva>
We clearly need to ensure a steady production of printed spec copies then
10:07
<hsivonen>
I have already recycled the paper of my printed copies
10:09
<Workshiva>
It might be an interesting exercise to see how many other specs would need to be printed together with HTML5 to actually preserve the technology
10:10
<jgraham>
Workshiva: Maybe HTML5 + the webkit source code + the gecko source code
10:11
<jgraham>
Since many of the other specs are insufficient
10:11
<jgraham>
(moreso than HTML5)
10:11
<Workshiva>
But then you'd also need to print the specs for the programming languages, and code or specs for all the libraries used too
10:12
<jgraham>
Is it turtles all the way down? What if the English language is mutated beyond recognition?
10:12
<foolip>
Are we considering sending HTML5 to an alien civilization for their consideration?
10:13
<Workshiva>
I'm assuming that English will have a large enough corpus elsewhere to count as axiomatically present
10:13
<jgraham>
"Aliens mock Earth in Markup language debacle"
10:13
<jgraham>
(with the right capitalization)
10:16
<crash\>
In most browser background colors from <body> are mapped to the whole viewpoint, even when the body element hasnt the full height of the viewpoint
10:17
<crash\>
Is there anything related to this in the specß
10:17
<jgraham>
Isn't that covered in CSS somewhere?
10:17
jgraham
doesn't remember if it is quirks vs standards mode but does remember it being explicitly specced
10:18
<crash\>
I'll look at the CSS spec
10:19
<Workshiva>
It's in CSS
10:19
<Workshiva>
For HTML documents, if there's no applicable style on html, the style on body is pushed up
10:19
<Workshiva>
I guess it was added to XHTML too a while back?
10:20
<crash\>
"user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element."
10:20
<crash\>
thanks
11:00
<hsivonen>
MikeSmithX: I got http://pastebin.mozilla.org/752429 when trying to respond to the versioning poll
11:27
hsivonen
wonders if wbs has a length limit on responses
11:27
<hsivonen>
my list of objections is pretty long
11:40
<hsivonen>
is http://sites.google.com/a/chromium.org/dev/spdy/spdy-protocol/spdy-protocol-draft2 the most recent SPDY spec?
11:43
<Peter`>
I read things about draft 3 in some chromium bug report, specifically about an extra bit for frame priorities, but that hasn't been published yet
11:47
<hsivonen>
ok
11:53
<jgraham>
foolip: BTW I started hacking on a little javascript WebSRT parser last night. So if you didn't already make one you are welcome to use that wehn it is finished
11:53
<jgraham>
It's not designed to be fast or useful or anything though
11:54
<jgraham>
Just to make me understand the spec a bit
11:56
<foolip>
jgraham, I'll be delighted to break it for you when it's done!
11:56
<jgraham>
foolip: That won't be hard
11:56
<foolip>
jgraham, is it in a public repo somewhere?
11:57
<jgraham>
foolip: It isn't even in a private repo yet
11:57
<foolip>
ok
11:57
<foolip>
let me know :)
11:57
<jgraham>
I just opened an emacs buffer and started typing :)
12:15
<zcorpan_>
jgraham: are you intending to have websrt node indirection?
12:16
<jgraham>
zcorpan_: I haven't read enough of the spec to know what that is yet :)
12:17
<zcorpan_>
jgraham: the output of the parser is "websrt nodes", and then there's a mapping to dom
12:17
<jgraham>
Oh I see
12:17
<jgraham>
Well yes then
12:18
<jgraham>
I am trying to implement what is in the spec more-or-less as written
12:18
<zcorpan_>
ok
12:18
<jgraham>
since the goal is not to be useful
12:18
<jgraham>
except as feedback
12:19
<jgraham>
So far my feedback is "this algorithm uses too much goto"
12:19
<jgraham>
(that is it doesn't trivially map onto a set of, possibly nested, loops)
12:21
<Philip`>
It's fun to implement these algorithms in functional languages which don't even have loops or break statements and certainly don't have goto
12:27
<Workshiva>
Lots of tail calls
12:29
<hsivonen>
I see no new objections at http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results
12:29
<hsivonen>
are others also seeing the Proxy Error or just not objecting actively?
12:33
<jgraham>
hsivonen: Didn't try since you saw an error
12:44
<hsivonen>
jgraham: ok.
12:44
<hsivonen>
it's a bit annoying that techincal problems with the polls themselves are hindering objecting
12:53
<MikeSmithX>
hsivonen: sorry, was away at dinner and just got back
12:54
<MikeSmith>
hsivonen: was one of your comments more than 5629 characters long?
12:55
<hsivonen>
MikeSmith: yes
12:55
<hsivonen>
about 7.8 KB
12:55
<MikeSmith>
whoah
12:55
<MikeSmith>
I have found that the WBS backend seems to currently have a bug related to length of comments
12:56
<MikeSmith>
if a comment is 5629 characters or longer, submitting a response will fail
12:57
<hsivonen>
what should I do when my objection is longer than that?
12:57
<MikeSmith>
a workaround is to post a comment to www-archive and then reference the URL in the WBS survery
12:57
<MikeSmith>
*survey
12:57
<hsivonen>
MikeSmith: ok
12:58
<hsivonen>
MikeSmith: thanks
12:58
<MikeSmith>
ym. sorry about the bug.. I don't have access to the WBS backend to troubleshoot it myself, but I have given teh systems team the details
13:00
<MikeSmith>
hsivonen: btw, I looked into seeing if I could implement http://bugzilla.validator.nu/show_bug.cgi?id=750 myself .. looked at the corresponding Xerces code to try to see what the LOE would be
13:01
<MikeSmith>
seems like it's more work than I had thought
13:01
<MikeSmith>
this is the "supply a DocumentBuilderFactory that instantiates HtmlDocumentBuilder, SAXParserFactory that instantiates sax/HtmlParser" enhancement
13:01
<MikeSmith>
Yudai: that bug might be another worth looking at
13:02
<hsivonen>
MikeSmith: more work in what sense? More work than just providing those classes? or writing those classes is more work than expected?
13:04
<MikeSmith>
hsivonen: I think the classes are all that's needed, but I meant writing the classes is more work -- the corresponding Xerces classes are several hundred lines, iirc
13:06
<MikeSmith>
hsivonen: the main reason I'm keen on getting that implemented is I really the HTML5 parser that can be easily usable as a drop-in replacement for an XML parser in existing toolchains
13:06
<MikeSmith>
there seems to be a common misconception that validation tools and such have to be based on XML parsers
13:07
<MikeSmith>
and so, that XML well-formedness needs to be requirement for validation and such
13:07
<MikeSmith>
I heard the misconception repeated on an ePub WG call I was on last night
13:08
<MikeSmith>
some developers involved with the prior epub work have developed a validator -
13:08
<MikeSmith>
http://code.google.com/p/epubcheck/
13:08
<MikeSmith>
that validator is based on jing
13:10
<MikeSmith>
I have not looked at their code yet, but if I were able to demonstrate that they could use it validate non-WF text/html content.. well, that would say a lot
13:11
<MikeSmith>
I mean, demonstrate that all they'd need to do is set a couple of Java system properties, and they could validate non-WF text/html content just as they can with XML/XHTML now
13:12
<MikeSmith>
Lachy: w3c mailing-list search and archived-at link-resolving are down now, and will be at least until midday US/East
13:14
<hsivonen>
MikeSmith: I objected by reference.
13:19
<MikeSmith>
hsivonen: thanks -- if the bug gets fixed before the poll closes, I will copy and paste the comment back in
13:19
Workshiva
wonders where dating HTML documents by doctype is a significant use case
13:19
<hsivonen>
MikeSmith: ok. thanks
13:19
<hsivonen>
Workshiva: if the author want to support document dating, the author could just write a *date* on the document...
13:20
<MikeSmith>
bingo
13:21
<MikeSmith>
I brings up the question of, What methods to do you use for trying to date *print* documents that are undated
13:22
<hsivonen>
MikeSmith: carbon dating?
13:22
<MikeSmith>
heh
13:23
<Workshiva>
Ink dating
13:23
<Workshiva>
I suppose it's possible to date the paper as well
13:24
<MikeSmith>
as long as we're on the subject, fonts and proportional spacing are one relatively easy visual indicator
13:25
<hsivonen>
does that mean that content displayed by Firefox 4 and content displayed by Safari are from different eras?
13:26
<MikeSmith>
I was thinking about specific case a few years back where some documents surfaced during the Bush vs. Kerry US presidential race that were supposedly from the 1970s
13:27
<MikeSmith>
and some supposed experts even verified that they were authentic
13:28
<MikeSmith>
but they were shown conclusively not to be, because they were very clearly produced using typesetting technology -- proportion character spacing and line spacing -- that were not widely available except to commercial printers
13:29
<MikeSmith>
and the documents were supposedly simple memos that some mid-level military official had typed up (or had a secretary type up)
13:30
<Workshiva>
Good times
14:31
<Slaanesh>
Opera using over 8 GB memory, sounds like a feature...
14:37
<jgraham>
Slaanesh: That doesn't sound good...
14:39
<Workshiva>
It was growing by 100 MB every few seconds until it decided to die a bit after 8 GB
14:39
<jgraham>
Can you file a bug?
14:40
<jgraham>
Also, which version of Opera?
14:40
<jgraham>
We made some fixes recently but I don't recall which shipped and which did not
14:44
<jgraham>
(If you file a bug, you get a bug number, right? Let gsnedders or I know)
14:44
<gsnedders>
jgraham: yeah
14:44
<gsnedders>
jgraham: Well, you get an email address in the form of bug-number⊙boc
14:54
<Workshiva>
Or I could just use the bug tracker directly :P
14:54
<jgraham>
Workshiva: That too :p
14:54
<jgraham>
In that case s/let gsnedders of I know/CC gsnedders and I/
15:06
<Philip`>
Does anyone happen to know if common search engines treat &nbsp; as largely equivalent to " "?
15:28
<hsivonen>
Hmm. Is Spotify for Linux an NPAPI plug-in host?
15:29
<hsivonen>
is does it print stuff about some other NP_Initialize?
16:41
<AryehGregor>
jgraham, if no alt text is provided, what are screen readers supposed to provide other than filenames? Should they just always treat it as alt=""?
16:41
<AryehGregor>
That seems less useful than the app adding as alt text the filename that the user provided on upload (which is likely more comprehensible).
16:44
<Philip`>
AryehGregor: They could apply heuristics to determine whether the filename is likely to be unreadable garbage or potentially useful
16:44
<AryehGregor>
They could. Then if they tell it's garbage, what do they use instead?
16:45
<Philip`>
They could do the same things that the site publishing the content could do
16:46
<Philip`>
only they have more motivation to choose to do those things (since it affects their paying customers) and more experience than the site owner does
16:50
<AryehGregor>
They can't, because they don't have the same information.
16:50
<AryehGregor>
They don't have access to the original filename when the user uploaded the file, for example.
16:50
<AryehGregor>
Without widespread ARIA support, they also don't have programmatic access to captions and brief descriptions the user might have entered.
17:09
<jgraham>
AryehGregor: I would provide some generic text. Clearly what the UAs do now is actively harmful to their users
17:09
<jgraham>
"I" meaning "I as a UA author"
17:09
<AryehGregor>
jgraham, okay, but that's only mildly better. It's certainly worse than low-quality author-added alt text, yes?
17:10
<AryehGregor>
So it's a good argument for saying that authors should be required to stick in whatever cruddy auto-generated alt text they can come up with.
17:10
<jgraham>
AryehGregor: That is far from obvious
17:10
<AryehGregor>
jgraham, the example makes it seems clear at least in Flickr's case.
17:11
<jgraham>
AryehGregor: Only because the UA behaviour right now is so user-hostile
17:11
<AryehGregor>
The original filename is likely better on average than a stock message, at least if you heuristically filter out total gibberish.
17:11
<AryehGregor>
Maybe, but that's where we stand.
17:12
<jgraham>
If it just said something generic you could quickly get on with reading the rest of the page which may have more useful information e.g. tags, descriptions, titles, comments, etc.
17:12
<jgraham>
The user-uploaded filename will in most cases be just as meaningless as the flickr one
17:12
<jgraham>
since it is just autogenerated by their camera
17:13
<jgraham>
Indeed flickr uses that as the default title and when people don't change it it is actively annoying
17:13
<AryehGregor>
Hmm, that's true.
17:13
<AryehGregor>
For photos.
17:13
<jgraham>
So I would prefer they just left in blank there too
17:13
<jgraham>
*it
17:13
<AryehGregor>
For non-photo images it often won't be true, though, the name is often meaningful.
17:14
<jgraham>
AryehGregor: Maybe, it's hard to tell
17:14
<AryehGregor>
Still, if UAs implemented heuristics to not read gibberish filenames, they could apply them to alt text too.
17:14
<AryehGregor>
I don't know if it hurts to give the UA extra data.
17:34
<volkmar>
are submit controls not barred from constraint validation to let authors play with setCustomValidity() and :invalid?
17:42
<AryehGregor>
There's not much point in barring something from constraint validation if it can't become invalid without setCustomValidity() being applied, I guess.
17:50
<volkmar>
AryehGregor: input type='reset|button' are barred
17:50
<volkmar>
and button type='reset|button'
17:50
AryehGregor
doesn't know, then
17:50
<volkmar>
it looks like all submit controls are not barred
17:51
<volkmar>
and I don't think we should let any element being invalid with setCustomValidity
18:14
<dandaman>
soooo
18:15
<dandaman>
my javascript functions were fine yesterday
18:15
<dandaman>
then i added some css3 to make sliding transitions on my site
18:15
<dandaman>
http://pastebin.com/g2q8BSGn
18:15
<dandaman>
line 2 no longer works
18:15
<dandaman>
any idea?
18:16
<dandaman>
even if i take out that slidingtable line
18:16
<dandaman>
that slidingtable line works btw
18:16
<TabAtkins>
$('continueIMage') will only select a <continueImage> element.
18:16
<TabAtkins>
You probably want a . or # in there.
18:16
<dandaman>
<img id="continueImage" name="continueImage" src="/fax-signup-api/images/continue.png" onclick="if(!isLoading){getNumber($('resultsList').value);}">
18:17
<dandaman>
it was working fine yesterday
18:17
<TabAtkins>
No, $('continueImage') would never have worked at any point.
18:18
<dandaman>
i have mootools imported
18:18
<dandaman>
not sure if that makes a difference
18:18
<dandaman>
but it was working
18:18
<TabAtkins>
Just change it to $('#continueImage') and try it out.
18:18
<dandaman>
i threw in an alert right after the continue image line
18:18
<dandaman>
i tried # and .
18:18
<dandaman>
both didnt work
18:18
<dandaman>
rather the alert never showed
18:19
<dandaman>
it seems like the function just gets stuck at that line
18:19
<TabAtkins>
This is jQuery, right?
18:19
<dandaman>
yeah i have jQuery imported
18:19
<TabAtkins>
Why are you setting the onclick like that in the first place?
18:20
<TabAtkins>
$("#continueImage").click(function(){ displayPersonalDID($('resultsList').value()); });
18:20
<dandaman>
the code i salvaged had it like that, i'll change it to .onclick='display...'
18:20
<TabAtkins>
No, .onclick won't work either. The object returned by the $() function is *not* a DOM Node.
18:20
<dandaman>
ok that worked
18:21
<dandaman>
i'm not familiar with jquery, had no idea there was different syntax for that stuff, i am mainly using it to do the sliding transitions
18:21
<dandaman>
thanks
18:29
<hsivonen>
pretty low objector turnout so far
18:51
<hober>
hsivonen: for which poll?
18:55
<AryehGregor>
Where's frequency data on how often various elements are used? I always forget this kind of thing.
18:56
<AryehGregor>
Google did something on this, yes? But I forget what it was called.
18:56
<Philip`>
http://philip.html5.org/data/ has some :-)
18:56
<Philip`>
e.g. http://philip.html5.org/data/tag-count-pages.txt
18:57
<AryehGregor>
Thanks.
18:57
<Philip`>
You're probably thinking of http://code.google.com/webstats/
18:57
<Philip`>
though it's five years old now so things will have changed
19:09
<AryehGregor>
Philip`, how up-to-date is your data?
19:09
<AryehGregor>
The elements I'm looking at are way too marginal to show up in Google's stats.
19:11
<Philip`>
AryehGregor: The one I linked is quite old (maybe about two years?)
19:11
<AryehGregor>
k, thanks.
19:12
<Philip`>
I have the dotbot data that's more like a year old, if you want any numbers or searches from that
19:14
<AryehGregor>
No, basic data is fine.
19:14
<AryehGregor>
Someone was just asking for support for my claim that practically no one uses <kbd> or <samp>.
19:14
<AryehGregor>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9919
19:17
<hsivonen>
hober: both versioning and ascii-ref
19:23
<hober>
IIRC I thought the counter-CPs covered the arguments pretty well, so I haven't bothered to respond to either
19:23
<AryehGregor>
Is the beforeload event standardized anywhere?
19:23
<hober>
that said, I enjoyed reading your reply to the versioning poll
19:40
<AryehGregor>
Looks like everyone except Opera 10.60 does a lousy job of caching redirects, at least when cookies are involved: http://stevesouders.com/tests/redirects/results.php
19:40
<Hixie>
hober: btw, thanks for all the spam fighting on the wiki, i was banning someone last night and saw how much you'd done, nice work :-)
19:41
<hober>
Hixie: no problem
19:41
<hober>
anne usually catches the ones that make it past me
19:42
hober
is subscribed to the recent changes feed
19:42
<hober>
so I catch things pretty early
19:43
<AryehGregor>
browserscope.org is cool, I never knew about it.
19:45
<TabAtkins>
Agreed, pretty cool.
19:47
<estellevw>
wish they provided more detail about the tests
19:51
<estellevw>
Why is <hr> included in 'grouping' elements in the spec
19:52
<estellevw>
seems like an odd man out in that section
19:54
<TabAtkins>
Where is it listed as 'grouping'?
19:54
<Philip`>
In the table of contents, at least
19:55
<estellevw>
http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-hr-element
19:55
<TabAtkins>
Oh, right. ^_^ <hr> represents a paragraph-level break, grouping content in a way somewhat similar to the other grouping elements.
19:55
<Hixie>
"grouping" is a poor name
19:55
<Hixie>
but is the best i could come up with
19:56
<estellevw>
cause hgroup, which is in sectioning, feeling like 'grouping' is a better name
19:57
<estellevw>
'grouping' has meaning in itself that fits elmeents not in that group too
19:57
<estellevw>
though i can't come up with a better name either ;)
19:59
<estellevw>
how would you define "grouping"?
20:09
<estellevw>
i guess formerly block level elements are now divided into sectioning and grouping elements?
20:14
<slartsa>
anyone ever used kannel?
20:37
<cardona507>
TabAtkins: how was your talk the other day?
20:37
<cardona507>
slides?
21:06
<oal>
Is it possible to remove or change the appearance of the box/arrow of a <select>?
21:06
<TabAtkins>
No.
21:06
<oal>
Oh, ok
21:39
<Hixie>
oops, forgot to update subject line for the last e-mail
21:42
<Hixie>
crap, did it again!
21:50
jgraham
hums "and when the first email has the wrong subject he knows he's losing it, and when the second email has the wrong subject he knows he's losing it, oh yeah he's losing it oh yeah he's losing it"
21:50
<jgraham>
Hmm, that was wrong
21:51
<jgraham>
Ironically
22:18
<Hixie>
i need a freely redistributable pretty ASCII art image about 10 lines long
22:18
<Hixie>
anyone got anything that fits?
22:23
Lachy
wonders if Sergey is in here? Reviewing his blog post now
22:23
<aho>
http://whatwg.pastebin.com/Ppe5K1PK
22:23
<aho>
:>
22:24
<aho>
there lots of generators online by the way
22:24
<aho>
http://www.network-science.de/ascii/ <- used that one with the goofy font
22:25
<Lachy>
Hixie, do you have Astrophy in ASCII art?
22:25
<wirepair>
probably not what you had in mind, but an awesome ascii font generator i use: http://patorjk.com/software/taag/
22:29
<TabAtkins>
Hixie: Got a 20-line one with Patrick Stewart facepalming.
22:30
<jamesr>
TabAtkins: WANT
22:30
<TabAtkins>
http://www.jozjozjoz.com/2010/03/22/picard-facepalm-ascii-art/
22:30
<TabAtkins>
First place I coudl re-find it.
22:30
<TabAtkins>
Interestingly enough, it's done in a proportional font.
22:31
<TabAtkins>
I've seen a better one, though.
22:40
<colapop>
Is <nav> the best choice for a table of contents block or is there something more targeted?
22:41
<TabAtkins>
Nah, that's what you want.
23:11
<Hixie>
aho, TabAtkins: ok so just to clarify, i meant an image, not text, and by "freely redistributable" i meant "has a known copyright situation" :-P
23:11
<Hixie>
Lachy: unfortunately not
23:11
<TabAtkins>
Hixie: Wait, what? You want an image of text of an image?
23:12
<Hixie>
i want an image
23:12
<Hixie>
ascii art image
23:12
<Hixie>
a text/plain graphic
23:12
<Hixie>
not a text/plain graphic of text :-)
23:12
<AryehGregor>
Who's Sergey, and what blog post?
23:12
<TabAtkins>
...
23:12
<Hixie>
which is what aho suggested :-)
23:12
<TabAtkins>
So is this going to be text, or pixels?
23:12
<Hixie>
text
23:13
<TabAtkins>
Okay, that's what I thought. I was confused why you were telling me this.
23:14
<nimbupani>
Would it be appropriate to ask questions about inset box-shadows here?
23:15
<TabAtkins>
You could try, but they kind of confused me.
23:16
<TabAtkins>
s/ed/e/
23:16
<nimbupani>
ok :)
23:16
<nimbupani>
http://dl.dropbox.com/u/952/pola/index.html
23:16
<nimbupani>
(sorry please refresh)
23:16
<nimbupani>
so two images. the one on right has box-shadow without inset
23:17
<nimbupani>
the one on left has with inset.
23:17
<nimbupani>
so the box shadow on right renders correctly, but the one on left does not render at all, even tho spec says box-shadows apply to all elements.
23:18
<TabAtkins>
You been able to do get the inset to work on anything else?
23:18
<nimbupani>
yeah it works on non-img elms
23:19
<TabAtkins>
Then it's a browser bug.
23:19
<nimbupani>
but its like cross-browser :)
23:19
<TabAtkins>
Then file it on multiple browsers. ^_^
23:19
<TabAtkins>
There's no reason an inset shadow shouldn't work on an image.
23:20
<nimbupani>
yeah :(
23:25
<Lachy>
AryehGregor, Sergey is someone who e-mailed Hixie and i to review and publish a post on the whatwg blog.
23:29
<hober>
TabAtkins: how'd the panel go on Wednesday?
23:29
<TabAtkins>
Good times.
23:30
<TabAtkins>
I messed up my demo by hacking at it while starting the panel, but we saved it with another demo I'd written earlier.
23:30
<TabAtkins>
I recommend against flying twice in one day, though.
23:30
<TabAtkins>
I just wish we hadn't been kicked out of the room. I always love the Q&A - people ask great questions at places like that.
23:35
<estellevw>
nimbupani: The inset shadow is working
23:35
<estellevw>
it's just appearing behind the image
23:35
<estellevw>
set the opacity to 0.5, and you'll see what i mean
23:35
<nimbupani>
estellevw: but it should appear in front of it ideally :/
23:35
<TabAtkins>
Yeah, that's a bug. inset bugs go on top of the element.
23:36
<estellevw>
even on embedded content?
23:36
<TabAtkins>
Yes?
23:36
<estellevw>
spec unmemorized: if all browsers have same issue, that might need to be delineated
23:37
<estellevw>
should be a given, but ...
23:37
<nimbupani>
estellevw: i dont see the shadows on chrome/firefox as you said
23:37
<nimbupani>
oh wait let me use a higher pixel value
23:38
<nimbupani>
no o.
23:38
<estellevw>
nimbupani: I used firebug to set opacity to 0.5
23:38
<estellevw>
and change shadow to inset
23:38
<estellevw>
img {
23:38
<estellevw>
-moz-box-shadow:2px 2px 5px black inset;
23:38
<estellevw>
display:block;
23:38
<estellevw>
opacity:0.5;
23:38
<estellevw>
}
23:39
<nimbupani>
http://dl.dropbox.com/u/952/pola/index.html
23:39
<nimbupani>
i cannot see any shadow.
23:40
<estellevw>
FF 3.6.7
23:41
<Hixie>
man i cannot find any ascii art with a clearly reusable copyright license
23:41
<nimbupani>
I am on that too, can you send me a screenshot?
23:41
<nimbupani>
use gyazo if you can :)
23:42
<estellevw>
so weird. I reloaded and it disappeared. Where should i send screenshot?
23:42
<nimbupani>
let me PM you.
23:51
<estellevw>
so, if a box shadow is placed on a transparent gif, you can see it. The image is appearing on top of the shadow, not the other way around
23:51
<TabAtkins>
Yeah, that's definitely a bug.
23:55
<estellevw>
nimbupani: did you change the code, because now it's work in Opera 10.6, but it wasn't before
23:56
<nimbupani>
the image on the right will work.
23:56
<nimbupani>
because it is transparent png.
23:56
<nimbupani>
so you are right it IS rendering box-shadow but changing opacity will not show that.
23:56
<estellevw>
ah, ok
23:56
<nimbupani>
but using transparent png does.