00:00
<roc>
It's really not a problem
00:00
<roc>
it's just extra code
00:01
<Hixie>
k
00:01
<Hixie>
i get the feeling some of the other implementations have the opposite situation because they just hand the whole shebang over to a Multimedia Framework and have that figure it out on its own
00:02
<roc>
yeah, for them it's definitely easier to sniff
00:02
<roc>
if you have a framework that always sniffs
00:02
<roc>
like Quicktime
00:04
<roc>
Hixie: I think kinetik and I are pretty much resigned to sniffing everything at this point, but doublec may not be, so I'll get him to chime in when he shows up
00:04
<Hixie>
awesome, thanks
00:04
<Hixie>
i'm hoping we don't have to sniff everything
00:05
<roc>
ok
00:05
<Hixie>
i'm hoping we can do what opera does rather than safari/IE/chrome
00:05
<Hixie>
which is to use the mime type as a "no" but not as a "yes", basically
00:05
<Hixie>
so it can be wrong, so long as it's a supported type
00:05
<Hixie>
since that at least has the benefit of minimising network usage
00:06
<roc>
I suspect you'll get a lot of pushback against that from Apple, but I should let them speak for themselves
00:06
<roc>
we'd certainly be happy with that if you can get everyone on board
00:07
<Hixie>
yeah i've been trying to get in touch with the relevant apple people
00:08
<Hixie>
i don't even know who to contact on the IE side
00:48
<TabAtkins>
Hixie: Can we get @srcdoc to imply @sandbox? Sandboxing is basically the entire *point* of @srcdoc, and it would help security in the common case.
00:49
<Hixie>
i'm not a huge fan of implying security attributes, but maybe... does abarth have an opinion?
00:49
<TabAtkins>
Haven't asked him; I was just talking to jschuh, who's implementing @srcdoc right now.
00:50
<Hixie>
it'd be good to get his take on it
00:50
<TabAtkins>
I'm just afraid of it being common for authors to do <iframe srcdoc="<script>evilcode()</script>"></iframe> and not realizing that this is insecure.
00:50
<Hixie>
yeah, understood
00:51
<Hixie>
it removes the ability to not have a sandbox though
00:51
<Hixie>
and often you'll want to say sandbox=allow-same-origin or whatever the keyword is
00:51
<Hixie>
and also add seamless
00:51
<Hixie>
so will it really help? hard to say
00:51
<TabAtkins>
If you don't need a sandbox, then you can just splice it into your page directly.
00:52
<Hixie>
not always
00:52
<Hixie>
it can be convenient to stick something in its own document
00:52
<Hixie>
agreed that it's not the main use case though
00:52
<TabAtkins>
Asking abarth now.
01:00
<TabAtkins>
abarth says it sounds godo.
01:01
<TabAtkins>
I'm thinking that for the more advanced use-cases that want an iframe but not the sandbox, we can just say "use data: urls".
01:01
<abarth>
does this cause problems for @seamless?
01:02
<Hixie>
i don't think it causes problems
01:02
<abarth>
you want srcdoc+seamless to work without sandbox="allow-same-origin"
01:02
<TabAtkins>
Do you?
01:02
<Hixie>
i just assumed you'd still have to list sandbox explicitly if you wanted seamless
01:03
<abarth>
isn't the common case that you want srcdoc + seamless + all the sandbox bits turned on
01:03
<abarth>
e.g., blog comments
01:03
<Hixie>
not all of them, but yes
01:03
<Hixie>
not all the bits, i mean
01:03
<abarth>
which bits do you want off in the common case?
01:04
<abarth>
put another way, the reason restrict @seamless to same-origin is to stop you from screwing with / learning about other people's content
01:04
<abarth>
but if the content comes from srcdoc
01:04
<abarth>
it's your own content anyway
01:04
<Hixie>
you want allow-same-origin and maybe allow-top-navigation, but you probably don't want allow-forms or allow-scripts (or allow-plugins when we have updated the API)
01:05
<abarth>
i keep forgetting that allow-top-navigation is really useful when you have script disabled
01:05
<Hixie>
(you definitely don't want allow-forms or allow-scripts if you have allow-same-origin)
01:06
<mcarter>
anyone happen to know what verison of javascript IE9 supports/will support?
01:06
<Hixie>
(you usually don't need allow-top-navigation if you have seamless)
01:06
<abarth>
it complicates the model, but i seems like we should let @seamless work for srcdoc documents, even if they're sandboxed into a different origin
01:07
<TabAtkins>
I'd like @seamless to work with @srcdoc, without necessarily even saying @sandbox=allow-same-origin.
01:07
<TabAtkins>
Yeah.
01:07
<Hixie>
that would need careful thought
01:07
<Hixie>
but seems reasonable on the face of it
01:07
<Hixie>
send mail
01:07
<abarth>
ok
01:07
<TabAtkins>
Kk.
01:07
<abarth>
btw, there's a patch under review in webkit to add srcdoc
01:08
<TabAtkins>
https://bugs.webkit.org/show_bug.cgi?id=43683
01:08
<abarth>
so now is a good time to work out these things :)
01:08
<abarth>
no seamless yet though
01:08
<abarth>
TabAtkins: are you sending this mail or am i?
01:08
<TabAtkins>
I can do it.
01:08
<abarth>
thx
01:08
TabAtkins
will send it tomorrow morning.
01:09
<abarth>
getting the HTTP WG to do anything is ridiculously painful
01:11
<Hixie>
looks like we already allow text/html-sandboxed to be seamless when it's not sandboxed, even though it's cross-origin
01:11
<Hixie>
this seems equivalent
01:13
<abarth>
Hixie: yes
01:13
<AryehGregor>
mcarter, IE9 aims to support ES5, from what I read.
01:15
<mcarter>
AryehGregor, thanks
01:16
<TabAtkins>
Hixie: re html-sandboxed and seamless, are you referring to the line "or the browsing context's active document's address has the same origin as the iframe element's document"?
01:16
<Hixie>
yeah
01:16
<TabAtkins>
kk
01:16
<Hixie>
that's the only case i can think of off-hand
01:17
<TabAtkins>
I was wondering about that, since a naive reading seems to make it equivalent to the other horn of the or clause.
01:17
<Hixie>
there are lots of cases of a url being cross-origin but the doc being same-origin, but the only case i can think of of a url being same-origin but a doc cross-origin is html-sandboxed
01:20
<abarth>
why not just @sandbox ?
01:20
<TabAtkins>
?
01:20
<abarth>
@sandbox doesn't alter the URL of the document
01:20
<abarth>
it just makes it cross-origin
01:21
<abarth>
you can't tell if something is same-origin by looking at it's URL
01:21
<TabAtkins>
Right, that'll do it too.
01:21
<TabAtkins>
Yes.
01:21
<abarth>
it's URL just initializes the origin
01:24
<Hixie>
abarth: the sandox case is handled separately in this instance
01:24
<abarth>
ah, ok
01:49
<boblet>
Hixie: re: use cases for time element, your March 2009 summary email lists automated adding to a calendar, restyling dates for user conventions and encoding output of input element unambiguously. Is that still accurate?
01:49
<boblet>
ref: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
02:01
<Hixie>
boblet: yes, though also add a less-dubious-than-abbr solution for microformats and microdata encoding dates
02:03
<boblet>
hixie: ok. I’m curious about year and year-month. for adding to calendar, what about future dates which are not yet confirmed? eg 5 year plans
02:04
<Hixie>
do you have an example of a page where it would be helpful for the user to be able to add a five-year plan to his calendar by clicking one thing on the page?
02:06
<boblet>
personally I’d like to add dates for future events I’m organising (Web Directions) to my calendar, but adding a day when they’re only accurate to a month seems like false detail.
02:06
<boblet>
current workaround is to add for the first of the month then try to remember what dates are set and which ones are vague
02:07
<boblet>
(these are on a private planning site)
02:14
<Hixie>
wouldn't it be more likely that you'd add those to the calendar before making a web page
02:23
<boblet>
Hixie: there are several of us planning, plus others who need read/write or just read access. I’m making a list of dates in the planning site, then we’re adding dates to a shared Google Calendar. However I’d also like to do this from HTML
02:25
<Hixie>
you just want to add the dates? not event names, locations, etc?
02:25
<boblet>
(that way I’d only have to make the page with event info inc. microformatted dates, not add the events to a calendar plus make the page)
02:31
<Hixie>
i don't follow
02:32
<boblet>
Hixie: I’d like a list of events in a planning site, plus to be able to add them to a calendar. current process is create events in calendar plus create list on planning site. with microformats I could just do planning site then one-click to add to calendar
02:32
<boblet>
(the less time in iCal.app the better :/ )
02:40
<knowtheory>
sup?
02:40
<knowtheory>
oops sorry wrong channel :P
02:42
<boblet>
Hixie: for the 2nd point (automatic formatting to follow user conventions), in Japan it’s common to write dates with kanji separators; 2010年8月20日. using time it’d be possible to do this automatically, but these also apply to year-month and year dates (eg weblog archive titles)
02:43
<boblet>
Hixie: for the 3rd point (encode output of input element unambiguously) that should apply to year-month input too, no?
03:01
<Hixie>
boblet: re your example, i don't see why you'd need anything new from <time> if you're going to use a microformat or microdata. For example, vEvent is based on dates as used with <time>, not months or years, iirc.
03:02
<Hixie>
boblet: even for multi-day or -year events
03:02
<Hixie>
boblet: regarding your 2nd point, good to know.
03:03
<Hixie>
boblet: regarding your 3rd point, i don't know; do people ever print the output of type=month in that way?
03:03
<Hixie>
the main use case for type=month is credit card expiry dates, but those get pretty printed easily as far as i can tell
03:04
<Hixie>
no need for <time> for that
03:04
<boblet>
Hixie: print the output? pretty printed?
03:05
<Hixie>
as in, sites just do printf "%04d-%02m", $year, $month
03:05
<Hixie>
or vice versa
03:05
<Hixie>
it doesn't need anything complex
03:05
<boblet>
Hixie: aah
03:05
<Hixie>
and might even actively not need anything complex, i dunno... how do japanese e-commerce sites echo expiry dates?
03:05
<Hixie>
what do japanese credit cards look like?
03:05
<boblet>
Hixie: I’m pretty sure I’ve seen Japanese ecommerce sites that have the year as 2-digit
03:06
<Hixie>
sure but do they have the kanji sepuarators?
03:06
<boblet>
Hixie: yeah, some Japanese credit cards have the expiry date as eg 10/15
03:07
<boblet>
(with English “Month/Year” printed faintly above)
03:07
<boblet>
but then there’s the whole Japanese year format thing… (wikipedia-ing…)
03:14
<boblet>
Hixie: found it; http://en.wikipedia.org/wiki/Japanese_era_name 2010 is actually 22年 (the 22nd year of the Heisei era). in long form today is 20-8-2010 or 2010年8月20日 or 平22年8月20日 (the 平 being the first kanji of 平成 or the Heisei era)
03:19
<boblet>
actually it would be useful to use <time datetime="1935">昭9年</time> (the ninth year of the Shōwa era) as even Japanese people have trouble with this system outside of dates they’re familiar with. I’ve got a free iPhone converter app for this :)
03:19
<boblet>
it’s still used for eg driver’s license DoB so not a historical thing yet
03:27
<boblet>
Hixie: I’ll add this info to the wiki page, want me to also email the list about it?
03:27
<boblet>
bbiab
03:39
<Hixie>
boblet: i likely won't see it if it's just on the wiki page :-)
04:50
hcr`afk
is back.. rejoice! ..[after 2120wks1day3h56m25s]
05:02
<boblet>
Hixie: ok, thanks
05:49
<MikeSmith>
Hixie: about the index of terms and handling of how to distinguish references to defining instances of terms from the others
05:49
<MikeSmith>
I implemented your suggestion
05:49
<MikeSmith>
http://dev.w3.org/html5/spec-author-view/index-of-terms.html
05:50
<MikeSmith>
the links to the defining instances are now just shown in the same order as they occur in document order
05:50
<MikeSmith>
in bold
05:50
<MikeSmith>
could of course maybe even make them a different color or something
05:50
<MikeSmith>
eventually
05:51
<MikeSmith>
but bolding them seems to make them stand out well enough
05:51
<MikeSmith>
one perhaps quirky thing is that some of them dfns are not the first mentions of the terms in the sections where they occur
05:52
<MikeSmith>
so instead of the hypertext for them themselves being a section title
05:52
<MikeSmith>
it is instead a counter number
05:53
<MikeSmith>
that is, one of the (2), (3), etc. numbers
05:53
<MikeSmith>
I had thought would turn out to look weird
05:53
<MikeSmith>
but even that seems to work OK
05:53
<MikeSmith>
to me at least
06:47
<Hixie>
MikeSmith: yeah, looks good. Probably should drop the "no references" thing though since now the dfns are basically references.
06:48
<MikeSmith>
Hixie: what about "no other references" maybe?
06:48
<Hixie>
i dunno that it even needs to be there at all, i mean, if you're looking up a term in an index, and there's only one reference, that's ok
06:49
<MikeSmith>
OK
06:49
<MikeSmith>
I will it so
06:49
<Hixie>
MikeSmith: not sure what to do about the conflicting terms... "align" in particular looks weird
06:49
<MikeSmith>
I will make it so
06:49
<MikeSmith>
yeah
06:49
<MikeSmith>
that's one of the downsides
06:50
<MikeSmith>
I can maybe work on figuring out how to merge those
06:50
<Hixie>
"command" is similarly kind of a disaster
06:50
<Hixie>
there's four of them and even i don't know which is which :-)
06:50
<MikeSmith>
heh
06:50
<Hixie>
oh you know what would be cool? if you could detect if the <dfn>ing instance used <code> or not
06:51
<Hixie>
so that elements got styled "correctly" in the index
06:51
<Hixie>
dunno how easy that would be
06:51
<MikeSmith>
that's doable
06:51
<MikeSmith>
that's easy
06:51
<Hixie>
cool
06:51
<Hixie>
this is awesome, i really love this index
06:51
<MikeSmith>
I think I could also deal with the align. command, etc., stuff by having anolis do another pass on the contents
06:52
<Hixie>
can't wait to see what it looks like for complete.html :-D
06:52
<MikeSmith>
and merging stuff
06:52
<MikeSmith>
heh
06:52
<MikeSmith>
yeah
06:52
<MikeSmith>
I will say that this is going to slow down your build/checkin times
06:52
<MikeSmith>
when you make changes
06:52
<MikeSmith>
dunno if you care
06:52
<Hixie>
a lot of the duplicates are in the non-conforming section, which makes merging them ok
06:52
<Hixie>
it's the other ones i'm worried about
06:52
<MikeSmith>
OK
06:52
<Hixie>
MikeSmith: does it slow down anolis? Or just the splitter?
06:52
<Hixie>
or what?
06:53
<MikeSmith>
anolis, mainly.. on my machine it takes about 6 minutes to have it build the author view
06:53
<Hixie>
oh yikes
06:54
<MikeSmith>
there might be some way I can speed it up, I dunno
06:54
<Hixie>
maybe we can have the spec splitters do the anolis pass as well
06:54
<MikeSmith>
yeah
06:54
<Hixie>
right now i subcontract out to jgraham's pimpmyspec for the anolis part, get one file back, then subcontract out to annevk and Philip`'s spec splitters, which send be tarballs back.
06:55
<MikeSmith>
hmm
06:55
<MikeSmith>
yeah
06:55
<Hixie>
but if i could just send a source file to anne and Philip` that would work fine for me too
06:55
<MikeSmith>
that can be combined for sure
06:55
<Hixie>
well i only do the splitting once i checkin at the moment
06:55
<MikeSmith>
it's all python
06:55
<MikeSmith>
ah, OK
06:55
<Hixie>
and the anolis part when i regen
06:55
<MikeSmith>
I see
06:56
<MikeSmith>
the anolis part was not terrifically fast before anyway
06:56
<MikeSmith>
I can't remember how long it took but it was a minute or two, it seemed like
06:56
<MikeSmith>
the splitter is much faster
07:57
<boblet>
nice work MikeSmith :)
10:02
payman
is back (gone 15:05:37)
11:16
<MikeSmithX>
http://twitter.com/jmalonzo/status/21651957160
11:17
<MikeSmithX>
【Is anyone here dual-booting their iPhone 4 with iOS and iPhoDroid? Interested to know how's it working for you #iphone #iphodroid】
11:18
<MikeSmithX>
I didn't even know there was a such thing iPhoDroid
11:18
<MikeSmithX>
I suppose it's only a matter of time before we have virtualization on the iPhone
11:19
<jgraham>
Personally I am waiting until the iPhone can unfold into a Back To The Future-style hoverboard
11:21
<MikeSmithX>
yes!
16:09
<jgraham>
So
16:09
<jgraham>
<svg><[CDATA[]]>
16:09
<jgraham>
A character token with the empty string or no character token?
16:10
<jgraham>
"""Consume every character up to the next occurrence of the three character sequence U+005D RIGHT SQUARE BRACKET U+005D RIGHT SQUARE BRACKET U+003E GREATER-THAN SIGN (]]>), or the end of the file (EOF), whichever comes first. Emit a series of character tokens consisting of all the characters consumed except the matching three character sequence at the end (if one was found before the end of the file)."""
16:11
<jgraham>
Suggests no character tokens, but it is not really clear
16:17
<Philip`>
jgraham: I thought character tokens contained characters, not strings
16:17
<Philip`>
and the empty string is not a character
16:18
<Philip`>
so it wouldn't make type-sense to have that
16:19
<jgraham>
Philip`: That could be true
16:20
<jgraham>
Philip`: the spec soesn't really say though
16:20
<jgraham>
it just says "Character tokens have data"
16:22
<Philip`>
It says "Character tokens"
16:22
<Philip`>
not "string tokens" or "text tokens" or "characters tokens"
16:22
<jgraham>
Right but "character" is just an opaque string unless it is defined
16:23
<Philip`>
so I'm generally willing to believe it's for a character
16:23
<Philip`>
though it could be more explicit
16:23
<Philip`>
Why is it more of an opaque strings than the words that would be used in its definition?
16:24
<jgraham>
Anyway, I agree with you
17:50
<variable>
can someone please explain the use-case behind <device> ? If you have ml references that would be better
17:51
<AryehGregor>
Input from web cams and microphones are the two biggest use-cases.
17:52
<variable>
AryehGregor, I'm a little confused then on how it would work
17:52
<AryehGregor>
It's not fully specced yet, is it?
17:53
<variable>
AryehGregor, no, but I'm not even sure what possible specs there could be. <device webcam>If you don't have a webcam then you see this</device> otherwise you see a permission box ?
17:54
<MikeSmithXX>
variable: https://labs.ericsson.com/blog/beyond-html5-implementing-device-and-stream-management-webkit may or may not provide some insights
17:54
<AryehGregor>
I don't think the spec will dictate UI.
17:54
<AryehGregor>
But that's the general idea. It's an element that will provide an API to read from various devices.
17:54
<AryehGregor>
I'm not sure why it's an HTML element instead of just a JS interface, though.
17:55
<variable>
Thats why I'm confused. I could only see this being used as a JS interface.
17:55
<variable>
I don't see what value an element offers
17:57
<AryehGregor>
Can't help you there.
17:58
<variable>
"Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation. " --> does this paragraph
17:58
<variable>
make sense? Should I change anything? it is meant to go under a section "It isn't just about web browsers"
18:11
<variable>
MikeSmithXX, thanks for that link btw
18:11
<MikeSmithXX>
yw
18:15
<AryehGregor>
Why does HTML5 link to the text versions of RFCs instead of the HTML versions? It seems a bit perverse, considering.
18:29
<Ms2ger>
AryehGregor, my fault, I guess. No good reason I can remember, file a bug if you want
18:30
<AryehGregor>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10411
18:32
<AryehGregor>
Yay, I slowed down all Firefox test runs by 90 seconds for no reason and no one noticed till now.
18:33
AryehGregor
remembered vaguely thinking about that when submitting the test, but no one said anything, so . . .
18:34
<AryehGregor>
I originally made it 65537 keypresses instead of 257, but even I noticed that was too slow.
19:01
<sean`>
ot,#mysql,#whatwg
19:01
<sean`>
fail
22:52
<Philip`>
http://store.steampowered.com/hwsurvey/
22:53
<Philip`>
"Adobe Flash Player 96.79%" - that's quite a lot
22:53
<gsnedders>
Yeah, a couple
22:53
<Philip`>
"Mozilla Firefox 63.05%" - that too
22:53
<Philip`>
"Microsoft Internet Explorer 19.82%" - I don't know how they're counting that
22:56
<llrcombs>
anyone know of a RTMP client in JS using WebSocket?
22:57
<Workshiva>
I thought the usual flash number quoted was 98%
22:58
<llrcombs>
I just thought "Hey, maybe if someone exposed a huge security flaw in Flash, people might stop using it!"
22:58
<llrcombs>
then I thought, "Wait, that's happened before, and people didn't stop using it (neither did web devs)"
22:59
<Workshiva>
Awh, Steam at 100%
22:59
<Workshiva>
I was hoping for a surprise there
22:59
<llrcombs>
lol
23:00
<Philip`>
I assume these numbers are hugely weighted towards home computers vs office computers, and somewhat towards more technical vs less technical users
23:01
<Workshiva>
Philip`: The browser entries add up to more than 100%, so it can't be default browser either
23:02
<llrcombs>
is it a survey or a detection software?
23:02
<llrcombs>
if it's a survey, it's possible that people interpreted as whatever software they _use_
23:02
<Workshiva>
It's most certainly detection
23:03
<llrcombs>
so... I've got nothing
23:03
<llrcombs>
anyone know anything abou that HTML5 RTMP client?
23:04
<llrcombs>
I dev a Safari extension that replaces Flash video players with HTML5 ones
23:04
<llrcombs>
RTMP is kinda pointless to use for media
23:04
<llrcombs>
and I don't support it
23:05
<llrcombs>
but still, to get more support for more video sites, I'd need an RTMP client
23:05
<llrcombs>
oh, RTMP/RTSP
23:06
<llrcombs>
ohwait RTSP is already supported
23:06
<llrcombs>
so I take back the RTSP bit
23:08
<llrcombs>
ROFLMAO @ http://www.6000rpms.com/blog/2010/03/11/dont-be-conned-html5-is-not-th.html
23:08
<llrcombs>
I can't find anything right about that article
23:09
<eric_carlson>
llrcombs: I don't think any browser supports RTSP at the moment
23:09
<llrcombs>
eric: Safari on OSX does!
23:09
<llrcombs>
because Core Video does!
23:10
<eric_carlson>
llrcombs: No, QuickTime supports it
23:10
<llrcombs>
am I mistaken?
23:11
<llrcombs>
I was under the impression that it did
23:11
<eric_carlson>
llrcombs: but Safari does not because it is disabled in WebKit (or was the last time I checked)
23:11
<midgard>
is there an html5 validator from the whatwg?
23:11
<llrcombs>
lemme test
23:11
<llrcombs>
migard: W3C has one
23:12
<llrcombs>
heh
23:12
<llrcombs>
I guess it doesn't!
23:12
<llrcombs>
wow
23:12
<llrcombs>
I wonder why that's disabled
23:12
<llrcombs>
sorry for my rudeness
23:13
<eric_carlson>
llrcombs: QuickTime does support RTSP, but WebKit blocks it because it caused crashes
23:14
<eric_carlson>
llrcombs: that was when antti originally added the media element to WebKit
23:14
<Philip`>
midgard: http://html5.validator.nu/
23:14
<eric_carlson>
llrcombs: it may work now as QuickTime has had many changes since then, but there hasn't been much demand for it so I haven't checked
23:15
<midgard>
Philip` thx
23:20
<llrcombs>
ahh, k
23:20
<llrcombs>
crashes D:
23:21
<llrcombs>
WTF is XHTML5?
23:21
<llrcombs>
LOL @
23:21
<llrcombs>
Additionally, Flash offers the ability to capture the local webcam and microphone and stream it to the server for archiving and/or redistribution.
23:21
<llrcombs>
HTML5 does not address any of these things.
23:21
<llrcombs>
umm... yes it does
23:22
<llrcombs>
lrn2<device>
23:22
<llrcombs>
@ http://www.6000rpms.com/blog/2010/03/11/dont-be-conned-html5-is-not-th.html
23:22
<Workshiva>
llrcombs: Technically, he's correct
23:22
<Workshiva>
Since <device> is part of post-HTML5 HTML
23:23
<llrcombs>
ooooh, it is?
23:23
<llrcombs>
wait, post-html5?
23:23
<llrcombs>
that implies that HTML5 is done
23:28
<Workshiva>
Well, HTML5 is mostly feature complete
23:29
<Workshiva>
New features are typically marked for "v2" or "v3", or some other not-now-but-later label
23:52
<midgard>
I thought <device> will be part of html6?
23:52
<midgard>
Or am I wrong?
23:56
<Hixie>
if i have my way, there won't be an "html6", we'll just have a continually maintained "html"
23:56
<Hixie>
that's what the whatwg site has now