00:13
<Hixie>
othermaciej: please file bugs, i'd be happy to move words around if it helps
00:13
<othermaciej>
Hixie: will do
00:13
<Hixie>
thanks
00:27
<othermaciej>
Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9491
00:59
<Hixie>
othermaciej: ta
01:31
<jonnybarnes>
Hey guys
02:00
<boblet>
MikeSmith: the wording of the footer element’s example about links in footer has changed in WHATWG spec, so you might want to update nav details box
02:03
<boblet>
s/element’s/element/ (or more precisely the example about links in the footer)
02:04
<boblet>
Hixie: given this change to nav, would the defining characteristic of a group of links that warrants nav still be that they’re important enough to have a title? something else?
02:05
<boblet>
eg, it seems the Exampland wiki footer links could also now be nav, so wondering if this is stylistic or if there’s still a reason they’re not
02:39
<JonathanNeal>
hey all
02:41
<MikeSmith>
JonathanNeal: what it be like
02:41
<JonathanNeal>
it be like this.... yo IE8 is scor'n 18/160 on html5test.com
02:43
<JonathanNeal>
Actually ... more like "hey guys, let's grill hotdogs tonight" "fo sho Jon" and everyone is over.
02:44
<MikeSmith>
who maintains html5test.com ?
02:44
<miketaylr>
it just showed up on twitter today, afaik
02:45
<JonathanNeal>
Niels Niels Leenheer
02:45
<miketaylr>
magically
02:45
<MikeSmith>
sounds like a fake name
02:46
<JonathanNeal>
Well, I accidentally wrote his first name twice, the ills of not copying and pasting.
02:46
<miketaylr>
too bad, Neils Neils is kinda catchy
02:47
<JonathanNeal>
I agree.
02:48
<MikeSmith>
it's an anagram for "See Hell Nine Re"
02:48
<MikeSmith>
which sounds much more like a real name
02:48
<MikeSmith>
HTML5 will unleash the Nine Rays of Hell in 2011
02:49
<miketaylr>
the good news is that 2011 is just around the corner
02:53
<MikeSmith>
one side product of public-html discussions is the innovative quoting non-conventions that people seem to come up with
02:53
<JonathanNeal>
Like?
02:54
<MikeSmith>
e.g., http://lists.w3.org/Archives/Public/public-html/2010Apr/0348.html
02:54
<MikeSmith>
ME] Yes
02:54
<JonathanNeal>
YOU] I can make you say things now too
02:57
<MikeSmith>
heh
03:00
<JonathanNeal>
YOU] We're releasing HTML5 this summer, so I can spend more time buying new iPhones.
03:00
<JonathanNeal>
ME] Wow! Great idea, Mike.
03:02
<paul_irish>
MikeSmith: http://twitter.com/rakaz is the html5test guy. already pinged him about some weak tests.
03:02
<paul_irish>
apparently the site's been out for a month.
03:02
<paul_irish>
funny how that happens
03:04
<MikeSmith>
it does seem like a useful site I guess
03:05
<MikeSmith>
even though its secret purpose is to quietly prepare for the unleashing of the Nine Rays of Hell
03:06
<JonathanNeal>
That is the ULTIMATE purpose!
03:06
<MikeSmith>
paul_irish: is dude using modernizer at all?
03:06
<paul_irish>
nah
03:06
<MikeSmith>
modernizr make that
03:06
<MikeSmith>
paul_irish: I wonder why he's not
03:06
<paul_irish>
that findmebyip.com site that's gotten a lot of play does, though.
03:06
<MikeSmith>
ok
03:07
<paul_irish>
theres a few things he's got i'm gonna pick up.. like output/progress/meter elements.. and undoManager
03:07
<miketaylr>
yeah, saw those
03:08
<MikeSmith>
"A “Browser” is a piece of software used to access & display the Internet on your computer. ".. thanks, sensei
03:08
<paul_irish>
miketaylr: im sure you saw him fall into the chrome webforms false positive trap
03:08
<miketaylr>
ITS A TRAAAP
03:08
<miketaylr>
paul_irish: yeah
03:08
<JonathanNeal>
A "Browser" is a giant turtle with spikes who wants to kill Mario ... wait.
03:09
<MikeSmith>
paul_irish: the Forms 2.0 detection on that site seems wacky
03:10
MikeSmith
compares it with results at miketaylr site
03:11
<paul_irish>
miketaylr has his UI tests that are a bit better
03:11
<JonathanNeal>
paul_irish, what do you guys think of the ie7-js scripts Dean Edwards maintained that would add hover and type="" support to IE? Do you think you'd ever implement stuff like that into Modernizr?
03:11
<paul_irish>
but they were necessitated because his earlier tests (same as these) did the same falsepositive shit in webkit
03:12
<paul_irish>
JonathanNeal: hover no. i'm not into parsing stylesheets. authors have been working around div:hover in ie6 forever
03:12
<paul_irish>
whats type="" support?
03:12
<miketaylr>
JonathanNeal: whatchu mean by type=""
03:12
<miketaylr>
o. what paul_irish just said
03:13
<JonathanNeal>
Oh, I was just talkin' about the new input types.
03:13
<JonathanNeal>
Oh he parsed stylesheets to add that support? I could build something like that.
03:14
<miketaylr>
oh you mean his web forms script
03:14
<miketaylr>
i wonder if he'll ever finish that
03:14
<Hixie>
boblet: one of the main advantages of <nav> is it lets speech readers skip navigation sections, so in footers it's not especially useful unless you want to style it
03:14
<JonathanNeal>
Maybe ... you guys are the experts ... I just talk a lot :)
03:15
<MikeSmith>
nav++
03:15
<MikeSmith>
I wonder why nobody has written a change proposal for removing nav
03:16
<paul_irish>
miketaylr: oh shittttt whoa.. http://code.google.com/p/webforms2/ our buddies weston and zoltan have been hacking on that too
03:17
<MikeSmith>
wow
03:17
<miketaylr>
ahh cool. i showed that to weston a while back
03:17
<miketaylr>
back when dean told me "it's beta, please don't blog about it" :/
03:17
<MikeSmith>
did they actually implement the repetition model too?
03:17
<miketaylr>
oh wait, no sorry. this is weston's old one
03:18
<boblet>
Hixie: unless you wanted to access those links I guess
03:18
<paul_irish>
MikeSmith: http://sourceforge.net/projects/wf2/forums/forum/466583/topic/1604767?message=3994714 looks like it?
03:18
<Hixie>
boblet: yeah, but who ever uses footer navigation links?
03:19
<MikeSmith>
paul_irish: hmm, yeah, 2006
03:19
<Hixie>
i mean, if they were meant for common use, they'd be up front
03:19
<boblet>
well, the Emperor of Exampland, for one
03:19
<boblet>
? ;-)
03:19
<miketaylr>
afaik, weston hasn't touched this in years
03:20
<boblet>
Hixie: I’m still fuzzy on what is and isn’t a major (née primary) navigation block though. the previous “footer links wouldn’t qualify b/c they’re random” was informative, but that’s gone now
03:20
<Hixie>
only the author can know what's major and what isn't
03:21
<boblet>
MikeSmith: the wording of the example about links in footer in the nav element has changed in WHATWG spec, so you might want to update nav details box
03:21
<boblet>
Hixie: sounds koan-y. me likes
03:22
<MikeSmith>
I still think it would be useful to have a standard way to distinguish primary navigation from secondary navigation
03:22
<Hixie>
primary navigation is first? :-)
03:23
<MikeSmith>
in document order? it could be last if the author wants to, and use CSS to position it
03:24
<MikeSmith>
seriously, the main distinction that most designers seem to make is between primary and secondary nav
03:24
<MikeSmith>
if you look at class values and such in more granularity
03:24
<MikeSmith>
but wtfu do I know anyway
03:24
<MikeSmith>
I'm not a designer
03:24
<MikeSmith>
and don't want to be
03:25
<MikeSmith>
CSS is just to frustrating
03:25
<MikeSmith>
*too
03:25
<boblet>
traditionally the hardcore standardista is content then site nav, but with the state of CSS positioning (…implementations) it pretty much always ends up being nav then content
03:26
<boblet>
s/standardista/standardista approach/
03:26
<boblet>
MikeSmith: CSS is great, it’s just the implementations that are … frustrating
03:26
<MikeSmith>
I guess we will know more after nav gets used -- I'd expect to see a lot of <nav class=primary> and <nav class=secondary> and such
03:26
<MikeSmith>
boblet: same could be said about many features of the web platform
03:27
<MikeSmith>
it's all great until you actually try to use it
03:27
<boblet>
given ppl who care about such things generally add skip links, that could be used as a designator of primary nav
03:28
<boblet>
generally only one “skip to nav” link, even if there are multiple things that could be marked up with nav
03:28
<boblet>
(although I’ve seen “skip to search”)
03:28
<MikeSmith>
Hixie: trying to implement http://dev.w3.org/html5/spec/text-level-semantics.html#guidance-for-conformance-checkers is giving me heartburn, man
03:29
<MikeSmith>
I really need to chat with hsivonen
03:29
<KaOSoFt>
boblet- Why should content be first than navigation? Sorry, I'm kind of new to this Web development topic.
03:30
<boblet>
KaOSoFt: the idea is that for content pages (ie not the homepage or the archives etc) the user generally wants to get to the content. For text-to-speech reading through the navigation and other stuff in the header takes time (visual equivalent is Flash loading animation)
03:31
<boblet>
KaOSoFt: hence skip to content links and putting nav after content in HTML (which as mentioned is generally a massive pita)
03:32
<KaOSoFt>
boblet- Hmmm, "content pages". I get it. Thanks. :)
03:32
<boblet>
KaOSoFt: happy to help :)
03:53
<othermaciej>
MikeSmith: have you found any of the conditions hard other than the paragraph/section one?
03:54
<MikeSmith>
othermaciej: the figcaption exception is PITA, though not really hard I suppose
03:55
<MikeSmith>
the fact that that you the figcaption can occur before or after the img in document order
03:55
<MikeSmith>
so have to hold off on that check until endelement event for the figure element
03:55
<othermaciej>
MikeSmith: I was gonna say - you could track that you are in a figure
03:56
<MikeSmith>
yeah
03:56
<MikeSmith>
we just don't have a similar case like this yet to steal from
03:56
<MikeSmith>
in the existing code
03:57
<MikeSmith>
we will after this, though, I guess
03:57
<MikeSmith>
though I hope we won't be needing any more of this kind of stuff
04:00
<othermaciej>
yeah I don't know what other requirements might be like this
04:01
<MikeSmith>
hopefully none
04:01
<MikeSmith>
because from where I sit, it's pretty much an anti-pattern for conformance criteria
04:02
<MikeSmith>
*for document-conformance criteria
04:03
<MikeSmith>
it's also a challenge to try to figure out how to provide a concise error message for this set of cases
04:03
<MikeSmith>
or impossible
04:03
<MikeSmith>
I think the only practical thing to do is to provide a link to some document that provides detailed guidance
04:04
<MikeSmith>
e.g., as with the "Use CSS instead" link we have now
04:05
<othermaciej>
MikeSmith: I would describe the error as just missing alt
04:05
<MikeSmith>
yeah
04:06
<othermaciej>
MikeSmith: then briefly mention there are some other alternatives for describing an image and link to the list
04:06
<MikeSmith>
I think "element img is missing required attribute alt" is just about all the error message itself can say
04:07
<othermaciej>
really, there's no ability to give anything more descriptive for a missing attribute?
04:07
<MikeSmith>
yeah, there is
04:07
<MikeSmith>
it can add what you just described
04:08
<othermaciej>
ok, good
04:08
<othermaciej>
I found a lot of suboptimal error messages during the conformance study, at some point I should be a good citizen and file more validator bugs
04:08
<MikeSmith>
what I meant is, just the description of what the actual error is, I don't know what else to have it say
04:08
<MikeSmith>
some of those I have fixed already
04:08
<othermaciej>
ah, right, as a short description, I think that is fine
04:08
<othermaciej>
yeah, I've seen some of your fixes going by
04:10
<othermaciej>
anyway - that's a mostly accurate description of the error, even though there are a few exemptions to the alt requirement
04:10
<MikeSmith>
right
04:25
<JonathanNeal>
heyo
04:35
<Hixie>
MikeSmith: file bugs
06:15
<Hixie>
othermaciej: any suggestions for a shorter term than "valid URL potentially surrounded by spaces"?
06:16
<othermaciej>
Hixie: "valid URL attribute value" is a little shorter (assuming that is equally accurate)
06:16
<othermaciej>
or even just "URL attribute value" if there is no need for the non-valid version
06:17
<Hixie>
i'd rather not call the syntax by where it's used
06:18
<Hixie>
that always ends up giving me trouble later when i reuse the syntaxes
06:21
<othermaciej>
"space-delimited URL"
06:24
<Hixie>
i'll just go with potentially surrounded by spaces, it's less ambiguous
06:34
<othermaciej>
it does seem like a pretty unambiguous choice
06:45
<MikeSmith>
me tries to figure out which way the wind blowing on adding presence of role=presentation as an exception to the alt-required constraint
06:45
<micheil>
morning good chaps & ladies.
06:46
<MikeSmith>
if it is favorable I could add it speculatively/experimentally now to the checker in the interest of giving something broader to test against
06:46
<MikeSmith>
or I could hold off and just do it for now as close to the existing spec as I can get
06:47
<MikeSmith>
micheil: hey
06:47
<micheil>
MikeSmith: if it weren't for the variations in spellings, we'd have the same first/last names.
06:48
<MikeSmith>
your first name has a (tm) in it also?
06:56
<Hixie>
MikeSmith: the role=presentation exception is pointless... it's longer than the alternative (just writing alt="", which implied role=presentation automatically)
06:56
<Hixie>
s/implied/implies/
06:57
<micheil>
MikeSmith: ah, no.
06:58
<micheil>
MikeSmith: besides, mine's more trademarkable
06:59
<MikeSmith>
Hixie: OK
06:59
<micheil>
hey, Hixie thanks for the slight tip last night on where to look for the protocol details on websockets, so far I've got the server accepting clients and reading the headers
06:59
<Hixie>
cool
06:59
<MikeSmith>
micheil: your parents clearly have more imagination than mine
07:00
<MikeSmith>
Hixie: how about aria-labelledby ?
07:01
<micheil>
Hixie: I've been working from a slightly different use case, so far all the server's I've seen don't make use of the path in the initial GET request
07:01
<micheil>
is it intended to be used?
07:01
<Hixie>
MikeSmith: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6496
07:01
<Hixie>
MikeSmith: yes
07:01
<Hixie>
er
07:01
<Hixie>
micheil: yes
07:02
<micheil>
Hixie: cool, do you know of any other servers they make use of it?
07:03
<Hixie>
micheil: i wrote one that does, but it's a hack :-) (i used it to smuggle in the username/password of the user, instead of sending it in the first frame)
07:03
<micheil>
so far most I've seen don't even parse the headers correctly
07:03
<Hixie>
yeah
07:03
<micheil>
because, theoretically there aren't any headers not allowed
07:04
<micheil>
plus, they use a fixed order for them, which isn't correct
07:04
<Hixie>
that's why the latest draft requires the servers to parse two headers, because otherwise the servers wouldn't parse any and would be vulnerable to a cross-protocol attack from HTTP
07:04
<MikeSmith>
Hixie: I see, thanks (about aria-labelledby)
07:05
<micheil>
two headers? I've missed that one.. I'll have to check up on it
07:05
<Hixie>
the two Sec-WebSocket-Key headers
07:05
<Hixie>
MikeSmith: as a general rule, ARIA is a layer above HTML, so it should be possible to take any HTML file with ARIA, remove all the ARIA, and not make the page less conforming
07:05
<micheil>
oh, I thought they were part of the first GET request
07:06
<Hixie>
micheil: they are
07:06
<Hixie>
micheil: by "header" i meant "field" in websocket terminology, my bad
07:07
<micheil>
okay
07:09
<MikeSmith>
Hixie: yeah, that does seems rational, thanks
09:33
<hsivonen>
ouch. Tony Ross misdescribed the fallback mechanism of <video> at MIX.
09:33
<hsivonen>
claiming that the fallback content is rendered if the codec isn't available
09:33
<hsivonen>
I wonder if they've implemented it that way in IE9
09:34
<hsivonen>
and I wonder how many MIX10 visitors will now assume they can rely on the described behavior
09:36
<MikeSmithX>
hsivonen: are you going to around still in a couple hours from now?
09:36
<MikeSmithX>
I really want to talk with you when you have time
09:36
<MikeSmithX>
but I need to head out for a bit first
09:44
<micheil>
Hixie: good lordy is that spec on WebSockets very complete with all basis covered..
09:58
<zcorpan>
Hixie++
09:58
<micheil>
Hixie: also, with the usage of read 8 bytes from the server/client, I've found an ambiguity: if it's in UTF8, 8 bytes would be variable
09:59
<micheil>
it may be 8 characters or it could be four
09:59
<zcorpan>
micheil: the random bytes only use characters in the ascii range
09:59
<micheil>
ah
09:59
<jgraham>
micheil: it need not be characters at all
10:00
<micheil>
so, in which case the characters would have a string length of 8
10:00
<jgraham>
+utf8
10:00
<jgraham>
micheil: It is better to think of it as a bytearray of length 8
10:00
<micheil>
:/
10:00
<jgraham>
Dunno is node.js supports that
10:00
<micheil>
not sure I have access to bytearray types
10:00
<jgraham>
concept
10:00
<micheil>
considering it's js
10:00
<jgraham>
Right
10:01
<jgraham>
Hopefully soon
10:01
<gsnedders>
js--
10:01
<zcorpan>
tc39--
10:01
<jgraham>
If the TC39 people pull their finger out a little
10:01
<micheil>
gsnedders: js++*Infinity.
10:01
<jgraham>
(it looks like WebGL will force the issue though)
10:02
<gsnedders>
I'm sorry, GWT has made me hate JS forever.
10:02
<jgraham>
Anyway, the point is that in a sensible languge (note: very few such languages exist) that makes a clear distinction between a string and a sequence of bytes
10:02
<micheil>
gsnedders: GWT's mainly java though
10:02
<gsnedders>
micheil: The JS it generates is horrid.
10:02
<jgraham>
you would treat the random bytes as bytes, not as a string
10:03
<micheil>
yeah, I'm not generating JS, I'm writing it.
10:03
<jgraham>
gsnedders: Presumably the anyone feels the same way debugging generated bytecode
10:03
<micheil>
well, I do have a byte buffer that I could use (interfaces with C), but that may be a little heavy
10:03
hsivonen
hopes the byte array issue gets resolved before any browser ships a release version with WebGL enabled
10:04
jgraham
seriosuly thinks it would help to replace all the variable names in GWT code with random english words
10:05
<jgraham>
But feels that eval might screw things up
10:07
<jgraham>
(the idea being it is easier to figure out what is going on if you can say that "sheep calls confuse which calls ancilliary" rather than "xzy calls dfg which calls ijk"
10:07
<jgraham>
)
10:13
<hsivonen>
it's sure nicer to figure out what GWT is doing if you possess the original Java source and can recompile without minification
10:14
<hsivonen>
what bits of Google Wave are open source?
10:14
<hsivonen>
is any of the front end GWT stuff Open Source?
10:18
<zcorpan>
annevk: i think it would be awesome if the top five hundred or so websites in each country were accessible
10:18
jgraham
wonders what metric you are using for top 500
10:19
zcorpan
is quoting annevk's blog
10:19
<jgraham>
I mean quite a few of those are probably porn. DO you get accessible porn?
10:19
<zcorpan>
it would be awesome
10:21
<gsnedders>
So, the alt text for images is just erotic writing instead of the pictures?
10:22
<zcorpan>
what about video?
10:23
<jgraham>
Yeah, I guess a transcript wouldn't help much
10:23
<annevk>
zcorpan, yeah, maybe I should have lowered the number, wasn't sure
10:23
<hsivonen>
http://diveintomark.org/archives/2006/07/27/imagination
10:25
<jgraham>
hsivonen: I didn't dount that there sould be a demand for accessible porn
10:25
<jgraham>
Well I did obviously
10:25
<jgraham>
But I didn't mean to
10:25
<jgraham>
I meant to doubt that it would be an alternative presentation of other porn
10:26
<jgraham>
rather than a totally different resource
10:26
<jgraham>
s/sould/would/
10:27
<jgraham>
s/dount/doubt/
10:27
<jgraham>
You know I read that several times and didn't notice that I had totally misspelt the key word in the sentence
10:30
<annevk>
now http://lists.w3.org/Archives/Member/w3c-archive/2010Apr/0039.html (Member-only) is interesting
10:30
<annevk>
finally some hidden agenda gossip
10:37
<micheil>
hmm.. what would be an example of the /resource name/ for a websocket on the server?
10:37
<micheil>
morning there jeremy (adactio)
10:37
<adactio>
Morning.
10:42
<jgraham>
micheil: Presumably it can be anything you want
10:42
<micheil>
hmm..
10:42
<micheil>
okay
10:42
<jgraham>
It is just an opaque string that gets used by the server however it choses
10:42
<micheil>
it's definition seems rather ambiguous, I don't know if it should be clarified (/cc Hixie )
10:43
<micheil>
under the definition, it states that it should be the resource given in the clients handshake, then there's two blank lines and something about True / False if encrypted
10:44
<micheil>
True if the connection is encrypted or if the server expected it to be encrypted; false otherwise.
10:44
<jgraham>
The two blank lines sound like they should be talking about the secure flag
10:44
<jgraham>
What document are you reading?
10:47
<zcorpan>
ok now someone needs to test for canvas bugs in flash cs5
10:48
<annevk>
hmm, I meant W3C Member-only above...
10:48
<jgraham>
annevk: What other type of Member could you have meant?
10:49
<jgraham>
whatwg Member I guess
10:57
<micheil>
http://www.whatwg.org/specs/web-socket-protocol/
11:00
<micheil>
same is present in the latest draft: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75#section-5.1
11:01
<annevk>
-75 and and the whatwg.org version are different
11:01
<micheil>
on may be more up-to-date
11:02
<annevk>
whatwg.org is
11:02
<micheil>
but the problem is present from about -67 onwards
11:02
<jgraham>
If you have a trunk gecko or webkit based browser to hand (or maybe even lynx or something) I seriously recommend using http://www.whatwg.org/specs/web-apps/current-work/complete.html?slow-browser=1#network
11:03
<jgraham>
It is always the latest version and you can link to any part you are having trouble with
11:03
<micheil>
that is hella slow, but anyway :)
11:03
<jgraham>
I think, but without complete certianty, that the slow-browser thing stops some scripts from running
11:03
<jgraham>
which makes it faster
11:04
<jgraham>
(but that might just be the main spec or I might have forgotten the right parameter name)
11:06
<zcorpan>
jgraham: ?slow-browser is right
11:06
<micheil>
hmm.. I suppose rather then setting my key_1 & key_2 to be the values of the two Sec-WebSocket_Key[1|2] fields, I should just set them to be the numbers, as that's all that's actually used, isn't it?
11:07
<micheil>
no, actually that's wrong.
11:07
<zcorpan>
the numbers and the number of spaces are used
11:07
<micheil>
yeah
11:07
<micheil>
I might have to make that a sub-method..
11:07
<micheil>
bbl. dinner
11:08
<micheil>
thanks for the help folks :)
11:10
<zcorpan>
hmm wonder if it's problematic if the client inserts the spaces at the start or at the end of the string
11:11
<annevk>
not if you have a WebSocket server
11:11
<annevk>
but if you do both HTTP and WebSocket you need some kind of switching before continuing parsing
11:12
<annevk>
or raw buffer access or something I suppose
12:18
<micheil>
annevk: the solution is to make proper use of the upgrade / connection headers
12:21
<annevk>
so if you are an HTTP server you parse the first bit as HTTP until you hit the upgrade header at which point you continue parsing using a WebSocket parser?
12:27
<micheil>
yeah
12:27
<jgraham>
FWIW I think assuming HTTP servers have a particular architecture is probably a bad idea
12:27
<jgraham>
including an architecture required to conform to the spec
12:27
<jgraham>
(HTTP spec that is)
12:28
<micheil>
jgraham: true, hence the reason I'm implementing my node websocket server on top of raw network sockets
12:28
<jgraham>
Especially for little-used features
12:29
<micheil>
I know that the headers in a websocket client are going to be in the format: GET {path} HTTP/1.1\r\n{headers}\r\n\r\n{body}\r\n\r\n
12:29
<micheil>
or something like that
12:29
<jgraham>
micheil: Right but from the point of view of websockets it means we should be wary of security features that might fail due to likely bugs in servers
12:29
<jgraham>
(i.e. I agree with zcorpan about the location of the spaces)
12:29
<micheil>
and then the headers are going to be separated as {key}: {value}\r\n
12:30
<micheil>
and according to the spec for websockets, you should be fine, however, I wouldn't think of sticking websockets and a httpserver on the same network process
12:30
<micheil>
(ie, reading from the same stream of data)
12:31
<jgraham>
Me neither but some people seem to want that
12:31
<jgraham>
Or something
12:31
<micheil>
you do two processes
12:31
<micheil>
different ports
12:32
<micheil>
eg, your webserver on *.host.tld:80, and then your websockets on say, ws.host.tld:80
12:32
<micheil>
or just host:80 for http, host:8080 for websockets
12:33
<micheil>
nothing actually stops the two network sockets from talking to each other, depending on how you architect your app, take PusherApp.com for example, they have a rails app somehow pushing data onto a websocket server
12:33
<annevk>
jgraham, requiring a WebSocket server to understand HTTP semantics is also bad
12:33
<annevk>
jgraham, same for a WebSocket client
12:34
<micheil>
annevk: there needs to be some form of handshaking, and if that's done over upgrade, so be it.
12:34
<jgraham>
annevk: It doesn't have to at the moment, really
12:35
<jgraham>
It just has to follow the spec
12:38
<micheil>
as far as I'm concerned, I'll leave the spec writing to the guys who are the computer scientists or know what they're doing. I'm just interested in implementing and using things to the spec.
12:39
<zcorpan>
micheil: the spec likely has a number of bugs. if you're implementing it, you might catch bugs as you go, and it'd be really useful if you sent comments about your findings
12:39
<micheil>
yeah
12:40
<micheil>
I will do, so far I've only had issues with wording on it
12:40
<zcorpan>
cool
12:41
jgraham
wonders how many people are actually Computer Scientists by training. I mean I know Hixie isn't (I know a few people are but most people I just have no idea)
12:42
<micheil>
jgraham: Hixie isn't? I always had the impression that a lot of the guys on the w3c board / the spec writers were computer scientists and things like that
12:42
<micheil>
and I'm sure if you asked most web developers, they'd think the same
12:42
<zcorpan>
raise hands, everyone, who are computer scientists?
12:43
<asmodai>
What's a computer scientist? Someone who theorizes about computer stuff?
12:43
<annevk>
jgraham, indeed, that's a good thing
12:43
asmodai
did 1 year of something akin to CS and then just quit uni altogether
12:43
<workmad3>
asmodai: that's one thing
12:43
<annevk>
jgraham, but it does assume HTTP server architecture that also want to implement WebSocket can deal with that
12:43
hsivonen
has a CS degree
12:43
<jcranmer>
although I'm still at uni, so....
12:43
workmad3
has a CS masters
12:43
asmodai
is one of those autodidact scary types
12:43
<workmad3>
I wouldn't say I'm a computer scientist though
12:44
Lachy
has an IT degree, which AIUI, is basically the same as a CS degree, but had a different name at my university.
12:44
<workmad3>
CS is more about research into areas of computing more than actual software development
12:44
<micheil>
I've so far done.. 1 subject in a computer science degree.. but that's only because I can't do studies fulltime with highschool still on
12:45
<workmad3>
and I'd say the majority of CS courses and CS professors couldn't program for toffee
12:45
jgraham
wonders how a course would program
12:45
<workmad3>
jgraham: bad phrasing there
12:45
<workmad3>
CS courses don't tend to teach people how to program
12:46
<workmad3>
they teach students some programming languages, and then it's pretty much ignored
12:46
<Lachy>
workmad3, do they teach more about hardware aspects of computing?
12:46
<jcranmer>
pretty much
12:46
<Lachy>
like processor architectures, etc?
12:46
<jcranmer>
although in the course I TA, I do make it a point to beat in good coding practices
12:47
<workmad3>
Lachy: some do, or they'll teach things things like language design principles, or automated program and theorem proving, or lots of advanced db theory
12:47
jcranmer
will be taking Advanced Algorithm theory, compiler theory, and ethics as CS courses next semester
12:47
<workmad3>
but (mine at least) stopped on the programming front at the point of 'you can churn out some basic code now, you're a programmer'... no use of VCS, no code design or architecture, basically nothing to make a decent software engineer
12:48
jgraham
notes that the theoretical CS courses seem the most interesting / useful
12:48
<jgraham>
(but that could be my bias)
12:48
<Lachy>
my IT course covered a range of subjects including Java, C++, HTML/CSS/JS, databases and SQL, with little bits about hardware
12:48
<jcranmer>
well, given the scope of a project in a class, using VCS is pretty much overkill
12:48
<Lachy>
also covered things like project development and management
12:49
<jgraham>
(because you can pretty easilly lean to program by programming but learning, say, analysis of complex algorithsm on your own is pretty hard)
12:49
<micheil>
that's rather confusing.. in that complete work webapp thing, the numbering of sections is totally different to in the IEFT drafts
12:49
<jcranmer>
I think the largest one I managed to hit was 1K lines in magnitude
12:49
<workmad3>
jcranmer: if it's over about 100 LoC, I'd want it in a VCS now
12:49
<workmad3>
although I'd probably use git and just keep it local admittedly :)
12:50
<jcranmer>
lemme rephrase... it's one or two files, essentially
12:50
<micheil>
workmad3: what, you mean you don't work like a designer? myclass.final.12.final.proposal.png
12:50
<micheil>
:P
12:50
<jcranmer>
VCS comes into play when either a) I want to publish it or b) it's too complex that changing a file or three at a time stops working
12:50
<workmad3>
micheil: heh :)
12:51
micheil
wonders if the whatwg specs are in a git repo..
12:51
<workmad3>
jcranmer: for me, VCS comes into play when a) I want to do some code
12:51
<jcranmer>
micheil: svn I believe
12:51
<jcranmer>
workmad3: wuss :-)
12:51
<workmad3>
it's just a standard thing to do for me now... especially with how easy it is to just create a git repo for it
12:51
<micheil>
hmm.. public?
12:52
<jgraham>
VCS and so on seem like practical skills that are really easy to pick up
12:52
<jgraham>
Kinda like a physics degree teaching you how to solder
12:52
<micheil>
what's physics got to do with soldering?
12:52
<jgraham>
(although I admit I am hopeless at soldering and when I had to do that in my physics degree I made a total mess of it)
12:52
<workmad3>
jgraham: there were people on electrical engineering course at my uni in the third year who couldn't solder
12:53
<jcranmer>
micheil: http://html5.org/tools/web-apps-tracker
12:53
<jgraham>
workmad3: I didn't say engineering on purpose
12:53
<micheil>
jcranmer: neat
12:54
<workmad3>
jgraham: my view personally is that if a uni course is claiming to teach programming, then they should teach the good habits that go with it
12:55
<workmad3>
anyway, I need to go get lunch
12:55
<jcranmer>
-20 points: used #include "mylib.c"
12:56
<jgraham>
(the rather strained analogy I was trying to make is that soldering is often a required skill for practising physicists. But the point of the degree is to make sure that you know about quantum machanics and relativity and ways of thinking about solving problems like a physicist, not about how to solder)
12:56
<jcranmer>
-100 points: code doesn't compile due to cyclic include structure (WTF?)
12:56
<micheil>
hmm.. with the ASCII case-insensitive comparing, would an implementor be expected to convert from UTF8 to ASCII to compare, or would change the variable value to lowercase and checking it against another value that is lowercase be sufficient?
12:57
<jgraham>
micheil: It is defined somewhere, but it basically means change ACSII uppercase to ASCII lowercase and leave all other characters untouched
12:57
<micheil>
yeah
12:58
<micheil>
so equivilant to javascripts string.toLowerCase
12:58
<Philip`>
That does Unicode lowercasing, I thought
12:58
<micheil>
uhh.. I'm not sure
12:58
<jgraham>
Yes, not equivalent, for the reasons Philip gave
12:59
<Philip`>
You just want tr/A-Z/a-z/ (or whatever the syntax is)
12:59
<micheil>
hmm..
12:59
<micheil>
yeah, so, I'd probably have to use regex, and then use a callback on it
13:00
<annevk>
or you could map A-Z to a-z and then compare
13:01
<micheil>
huh?
13:01
<annevk>
but if you implement in JS I guess regexp might be faster
13:01
<micheil>
yeah, I think so
13:47
<micheil>
how does one report a bug?
13:47
<micheil>
oh, wait, not a bug
13:58
<erlehmann>
how does one report a feature ? hehehe
13:58
<annevk>
local authorities
14:00
<micheil>
erlehmann: no, it was just the way I read it
14:00
<micheil>
"append ws:// or wss:// to the url"
14:01
<micheil>
it sounds like you would get the url being: example.comws://
14:01
<micheil>
until you read that it's actually url begins empty
15:08
<annevk>
nessy, it's not reserved, just pointing out how it might affect existing features
15:09
<nessy>
I think that would be a nice side-effect actually!
15:11
<nessy>
I don't actually think the attribute name makes much of a difference - but sure, we gotta pay attention to details ;)
15:59
<annevk>
hsivonen, it should be srclang then arguably
15:59
<annevk>
hsivonen, or s/src/href/ but that seems worse
16:00
<hsivonen>
annevk: yeah, I noticed but I went with hreflang still
16:00
<hsivonen>
annevk: do you have an opinion on my concrete captioning mechanism suggestion at the end of the email?
16:04
<annevk>
not really sure what to think about pseudo-HTML for captioning to be honest
16:04
<annevk>
it sure beats TTML
16:05
<hsivonen>
it's not pseudo! innerHTML is the real thing!
16:05
<annevk>
heh
16:06
<annevk>
it does seem relatively straightforward
16:06
<annevk>
and much more Web-like
16:07
TabAtkins
boggles at 7 XML namespaces.
16:28
<TabAtkins>
hsivonen: How are you proposing that the time of the text string be encoded in the HTML version?
16:28
<annevk>
it's just SRT with HTML instead of text
16:28
<TabAtkins>
So you still write a number, followed by a time range, then followed by some HTML and finally a linebreak?
16:29
<TabAtkins>
s/linebreak/empty line/
16:29
<annevk>
yeah
16:30
<TabAtkins>
ok
16:30
<jgraham>
I swaer I saw a caption the other day where they blurred a swearword
16:30
<TabAtkins>
Um.
16:30
<jgraham>
But I was very unsure afterwards if I had just imagined it
16:30
TabAtkins
will be brb, rebotting.
16:30
<jgraham>
I always knew TabAtkins had to be a bot
16:33
<micheil>
question: how does one work out in the websockets if key-number1 is not an integral multiple of spaces1?
16:34
<micheil>
is it simple a Mod style expression?
16:34
<jgraham>
Yes
16:34
<micheil>
right
16:35
<micheil>
so what, key_number1 % spaces1 ?
16:35
<jgraham>
== 0
16:36
<jgraham>
or != 0 I guess
16:36
<micheil>
yeah
16:36
<jgraham>
or !== in javascript :)
16:36
<micheil>
good point there too
16:36
<micheil>
bitwise vs standard
16:37
<jgraham>
Well type converting vs non-type converting
16:37
<jgraham>
("non-strict" vs "strict" in ES-spec parlance)
16:38
<micheil>
yeah
16:40
<gsnedders>
(of course unrelated to strict-mode)
16:40
<gsnedders>
(I <3 the ES spec)
16:40
<micheil>
it's surprising how many people are implementing websocket servers wrongly
16:40
<jgraham>
micheil: The spec changed recently
16:41
<jgraham>
I expect they are implementing the old spec
16:41
<micheil>
not that greatly though
16:41
<jgraham>
or rather implemented
16:41
<micheil>
in the sense that they are using fixed header fields and very fixed input
16:42
<jgraham>
Well the whole handshake thing is new
16:42
<micheil>
ah, fair enough
16:42
<jgraham>
And there were lots of people pressing to make it easier to implment on top of an existing HTTP server
16:45
gsnedders
wonders what made Hixie change his mind
16:45
gsnedders
was arguing that within a few months of him spec'ing out the original WS draft
16:45
<micheil>
I wouldn't want websockets on top of http.
16:46
<micheil>
http has a fair bit of extra data baggage, compared with a raw tcp socket
17:00
jgraham
proposes ircroulette where you get dumped into a random irc channel until you leave or someone kicks you
17:00
<jgraham>
and then you get dumped into the next channel
17:01
<jgraham>
and then finally you get dumped by your SO for spending too much time on the internet, become depressed and die
17:02
<gsnedders>
I guess this is the advantage of not having a SO, you just skip right to the become depreessed and die part, hence wasting less time.
17:02
<gsnedders>
Optimization ftw.
17:02
<jgraham>
Nah, you just have to pick one up in one of the irc chennels along the way
17:03
<jgraham>
*channels
17:03
<gsnedders>
But I thought all dating IRC channel were 18+!
17:03
<jgraham>
Do you now understand *random*?
17:04
<jgraham>
*not
17:04
<jgraham>
sigh
17:04
<gsnedders>
jgraham's a terrible typist.
17:04
<jgraham>
Yes
17:04
<jgraham>
Sorry
17:04
<gsnedders>
You better be!
17:05
<gsnedders>
I've got a bottole of Irn-Bru and I'm not afraid to use it!
17:05
<gsnedders>
*bottle
17:05
<jgraham>
I'm a bee?
17:05
<jgraham>
Are you planning to use the Irn-Bru like jam at a picnic?
17:06
<jgraham>
(that is a waste of good Irn-Bru)
17:06
<gsnedders>
Well, no. More just to scare you with it's bright orange colour.
17:06
<gsnedders>
*its
17:55
<AryehGregor>
Why is Ian listed as the only editor in the W3C Editor's Draft, but David Hyatt listed as a second editor in the WDs?
17:56
<gsnedders>
AryehGregor: hyatt no longer an editor
17:56
<AryehGregor>
So the next WD won't list him as an editor?
17:56
AryehGregor
needs a source to cite to revert http://en.wikipedia.org/w/index.php?title=HTML5&diff=355515922&oldid=355096550
17:56
AryehGregor
suspects linking to the SVN logs would be considered "original research"
17:57
<gsnedders>
Indeed not
17:57
<AryehGregor>
Do you know of anywhere this is written down that I can cite?
17:57
<gsnedders>
Linking to the editor's draft would be to, but what else can you cite?
17:58
<gsnedders>
What does it currently cite?
17:58
<AryehGregor>
I mean, like, was a change agreed upon somewhere to remove David Hyatt's name as an editor?
17:58
<AryehGregor>
It currently cites the latest WD.
17:58
<gsnedders>
Then change it to cite the latest ED
17:58
<AryehGregor>
That's what I'm doing.
17:58
<AryehGregor>
I was hoping there'd be a clearer source, though.
17:59
<gsnedders>
othermaciej sent something to public-html
17:59
<miketaylr>
AryehGregor: http://lists.w3.org/Archives/Public/public-html/2010Apr/0096.html
17:59
miketaylr
wasn't sure if he imagined that
18:00
<AryehGregor>
Oh, thanks.
18:00
<AryehGregor>
Serves me right for not keeping up.
18:01
<AryehGregor>
It's fun to come across old posts by your n00b self: https://bugzilla.wikimedia.org/show_bug.cgi?id=986#c12
18:01
<AryehGregor>
"my HTML skills are fairly modest"
18:01
<gsnedders>
AryehGregor: You're probably more up to date than the guy who sent the first ever message to whatwg.
18:01
AryehGregor
doesn't get what that means
18:02
<gsnedders>
He's get a tens of thousands of unread emails :)
18:02
<micheil>
jgraham: hmm.. the WebSockets security stuff is probably going to take a while to implement..
18:03
<TabAtkins_>
gsnedders: The one about the XML submission format?
18:03
gsnedders
can't remember what it's about
18:03
<TabAtkins_>
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-April/000000.html
18:03
<gsnedders>
Yeah
18:03
<inimino>
when was all this Sec-WebSocket-Key1 and Key2 stuff added to Web Sockets?
18:04
<micheil>
oh. hey inimino
18:04
<micheil>
:P
18:04
<inimino>
oh hey micheil ;)
18:06
<inimino>
I remember the ideal of having Web Socket servers be written in a few lines of Perl, did that die in the IETF?
18:08
<micheil>
I suppose until I get the Security stuff working, I can leave it out
18:08
<jgraham>
micheil: To stop cross-protocl attacks
18:08
<jgraham>
*protocol
18:12
<gsnedders>
inimino: It still can be done in a few lines of Perl. It just depends how readable you want your Perl to be.
18:13
<inimino>
gsnedders: indeed :)
18:16
<TabAtkins_>
<keygen> is generally not something we like, right? It's only specced because it's common on the web and a few browsers have at least parsing support for it?
18:17
<jgraham>
TabAtkins_: Right
18:17
<jgraham>
(alos because we don't have a good other solution for the use cases)
18:17
<TabAtkins_>
k, was just making sure before I responded to the one email about it.
18:18
<TabAtkins_>
Well, hrm. I still don't know enough to respond to the email correctly. :/
18:20
jgraham
discovers that magic from-the-intertubes package delivery+installation isn't so good when the tubes get diconnected
19:06
<mbelshe>
annevk: yt?
21:05
<cardona507>
College4
21:11
<AryehGregor>
Neat, now Firefox has resizable text areas in 3.7. That's one of the features I actually notice missing when I use Firefox instead of Chrome.
21:12
<annevk>
mbelshe, am now
21:20
<TabAtkins>
Yay!
21:20
TabAtkins
loves resizable text areas.
21:21
<annevk>
mbelshe, ah, you mailed
21:23
<cardona507>
resizable text areas are pretty sweet
21:44
jgraham
wonders if setting pupils on a per-subject basis according to ability is legal in Sweden
21:54
<AryehGregor>
What do you mean?
22:00
<jgraham>
AryehGregor: Me?
22:02
<AryehGregor>
Yes, you.
22:03
<jgraham>
Having a setup where, for each subject, pupils are grouped according to their ability in that subject, and each ability group is taught seperately (typically for secondary eduction i.e. 11-16 but potentially for younger or older pupils too)
22:04
<AryehGregor>
You mean would it be legal for a private school to do that? I can't see why not. Or a public one?
22:05
<Dashiva>
In Norway the problem is bypassed with elective courses
22:06
<AryehGregor>
In America it's pretty typical to tier students by ability to some extent.
22:07
<AryehGregor>
Not that I really know, I went to a yeshiva.
22:07
<Dashiva>
(But we also have an acknowledged problem of gifted students being neglected in many places)
22:08
<jgraham>
AryehGregor: It is pretty typical in England too, especially in Maths, English and Science
22:09
<jgraham>
I caan't tell if it happens at all here but I at least know of schools that don't set in maths, which is very uncommon in the UK
22:10
<jgraham>
(because of the remarkable difficulty of teaching to the whole range of abilities without making half the class suicidal through either boredom or frustration)
22:10
<jgraham>
(that is, it is very uncommon not to set for maths in the UK)
22:11
<jgraham>
(or removing the double negative, it is very common to set)
22:12
<jgraham>
AryehGregor: I mean any school. The system of public/private schools is not quite the same as the US I think
22:13
<jgraham>
In particular there seem to be laws that restrict teaching practices in both
22:45
<Clubbed>
hi
22:49
<Clubbed>
why label="" attribute instead of tag? an attribute can contain only text, no markup... i mean that title="" attribute should be <tooltip>... attributes should contains technical informations like urls or ids classes, not visible text
22:50
<Hixie>
label=""?
22:50
<Clubbed>
yes
22:50
<Clubbed>
<menu type="context-menu" label="File">
22:50
<Hixie>
oh on <menu>
22:51
<Hixie>
because operating systems typically just ask for a single string for the menu labels
22:53
<Clubbed>
uhm
22:53
<Clubbed>
<label>ddd<b>d</b></label> label.textContent
22:55
<Clubbed>
limit ui designers means that no one will use label attribute
22:56
<Clubbed>
this is just my opinion!
22:56
<Clubbed>
that do you think about it hixie
22:57
<Clubbed>
*what
22:57
<Clubbed>
what do you think about
22:58
<Hixie>
i think if people want a context menu they'll use it :-)
22:59
<Clubbed>
no they will use a random old dhtml javascript context menu :D
23:00
<TabAtkins>
Why? So they can use <b> in their context menu?
23:00
TabAtkins
wants everyone to start being able to use <menu> yesterday.
23:00
<Clubbed>
yes, it is just an example
23:00
<Clubbed>
just like icon="" attribute
23:01
<Clubbed>
if i want to use two icons
23:01
<Clubbed>
?
23:01
<Clubbed>
and
23:01
<TabAtkins>
Your context menu is, fundamentally, a limited thing. When you right-click on things, you get a series of plain text labels that execute some command when you click on it.
23:01
<Hixie>
context menus on windows and mac don't generally have bold text and so forth, why would web authors want something fundamentally different?
23:03
<TabAtkins>
On any distro of Linux that I've personally experienced, too.
23:03
<Clubbed>
tabatkins
23:03
<annevk>
Opera context menus at least have a concept of bold
23:03
<annevk>
select some text, right click, see under "search with"
23:03
<Clubbed>
webapp should be independent (but integrated in the os)
23:04
<Clubbed>
so if the need is a text-only label
23:04
<Clubbed>
the syntax should be
23:04
<annevk>
i could imagine that if we ever "replace" the OS people would want to experiment beyond somewhat old-fashioned limitations too
23:04
<Clubbed>
<label value="String" />
23:04
<annevk>
but presumably you would not use <menu> then
23:04
<Clubbed>
so i can put icons around it
23:05
<TabAtkins>
Again, though, you don't see icons in right-click menus. They're just plain text strings.
23:05
<annevk>
Opera has icons in context menus
23:05
<TabAtkins>
Dammit, Opera!
23:05
<TabAtkins>
Why you gotta be complicating things.
23:06
<annevk>
we're full of win
23:06
<Clubbed>
they are not complicating
23:06
<Clubbed>
*complicated
23:06
<Clubbed>
fkg language difficulties xD
23:07
<Clubbed>
anyway tabatkins
23:07
<Hixie>
annevk: i wouldn't look at Opera for UI advice. :-P
23:07
<Hixie>
Clubbed: <menu> supports icons in context menus
23:07
<Clubbed>
yes but just only one
23:07
<Hixie>
um yes
23:07
<Hixie>
one per command
23:07
<Clubbed>
it's just an example of a limitation
23:07
<Hixie>
what's the use case for more than one per command?
23:08
<Clubbed>
i dont need more icons, but i think visible content should be placed inside tags, not attributes
23:09
<Clubbed>
for a lot of reasons
23:09
<Clubbed>
if i want to style only the label=""
23:09
<Clubbed>
how i should do?
23:09
<Hixie>
you can't style a context menu
23:09
<Hixie>
it's an operating system widget
23:09
<Hixie>
it's styled by the operating system
23:10
<Clubbed>
but is what designers want?
23:10
<Clubbed>
for example
23:10
<Clubbed>
facebook dropdown menus
23:10
<Hixie>
users are more important than designers, and users want their menus to be the same across all their applications
23:10
<Clubbed>
will use <menu> tag?
23:11
<Clubbed>
i think not
23:11
<Clubbed>
they will continue to use lists
23:11
<Clubbed>
or nav
23:11
<Hixie>
hey does anyone recall whether <time> is supposed to get replaced by its contents? I can't figure out where we last discussed this.
23:11
<TabAtkins>
I won't. I'd shoot people, right in the face, if that's what it took to get an OS-native right-click menu in my webapps.
23:12
<Clubbed>
tabatkins
23:12
<TabAtkins>
Hixie: ?_? You mean, like, converted automagically into the user's time settings?
23:12
<Hixie>
man, TabAtkins must have missed the "Life of Don't Be Evil" class
23:13
<TabAtkins>
I did! o_O
23:13
<Hixie>
TabAtkins: i mean <time datetime="foo"></time> being turned into locale-specific rendering of foo
23:13
<Clubbed>
my os controls must appear exactly like os skin defined they
23:14
<Clubbed>
i'm talking about context menus on gmail, on facebook, on wave, and toolbars too
23:14
<TabAtkins>
Hixie: I don't recall discussions about this, but that would be great.
23:14
<TabAtkins>
Clubbed: I'm also talking about those.
23:14
<TabAtkins>
And I want them to look like a right-click menu.
23:14
<TabAtkins>
Just like every single other application on my entire machine.
23:16
<TabAtkins>
I mean, I *actively desire* there to be no significant styling control of those things. Just like I don't want styling control of scrollbars.
23:16
<Clubbed>
ok, but is our "nerd" opinion, if you want to build an os-like application we can use xul, but "commercial" applications needs more styling and scripting features
23:17
<JonathanNeal>
BUT I WANNA MAK MA SCROLLBAHS PUPLE!
23:17
<Clubbed>
lolsdjfgsdf
23:17
<TabAtkins>
Apparently they don't. Commercial applications use ordinary right-click menus. And ordinary scrollbars. The *very* few that go out of their way to create custom versions of those are extremely annoying, though luckily quite rare.
23:18
<Hixie>
annevk: do you recall the current state of the <time> thing by any chance? whether we decided to make it not localise or something?
23:18
<Hixie>
the spec right now is inconsistent on the matter
23:18
<Hixie>
and i can't work out if it's just that i missed something while adding it or while removing it
23:19
<Clubbed>
tabatkins i see a lot of custom widget that they can not be reproduced with html5 markup
23:19
<Clubbed>
for example on wpf
23:19
<Clubbed>
i see textboxes inside the contextmenu
23:20
<TabAtkins>
I've never seen such a thing in any application I've ever used. :shrug:
23:21
<Clubbed>
me too, but i use only notepad++ and eclipse lol so maybe my idea of an application is "limited"
23:21
<TabAtkins>
I use plenty, and speak as a web designer who likes making pretty things.
23:23
<Clubbed>
anyway, you are right, people can't change color of our scrollbars but they do, so they will do the same with context menus, they will never use <menu>
23:24
<Clubbed>
xhtml teachs to us how it works
23:24
<TabAtkins>
I can't parse what you just said.
23:24
<Clubbed>
i'm sorry
23:24
<TabAtkins>
People do use scrollbars. They're a basic part of UI.
23:25
<TabAtkins>
And people do use context menus. They're all over the place. The one place they're missing is in webapps.
23:25
<Clubbed>
people cannot change the color of my browser scrollbar, but they inevitably do, with scripts
23:25
<Clubbed>
or flash
23:26
<Clubbed>
and they will use scripts instead of <menu>
23:26
<TabAtkins>
Very few people use scripts for context menus now. I doubt that will change.
23:26
<TabAtkins>
Adding <menu> will make context menus super easy to make, so I think you'll see them a lot more.
23:26
<Hixie>
very few people restyle their scrollbars. some do, but not many.
23:26
<Hixie>
the same will apply to <menu>.
23:26
<Clubbed>
... :| gmail does wave does everything on google does, social networks too
23:27
<Hixie>
some will go out of their way to do special menus, but most will do the right thing and use the OS default
23:27
<TabAtkins>
Gmail doesn't.
23:27
<TabAtkins>
Some of the Google apps do, but they're not doing anything that can't be handled by <menu>.
23:28
<Clubbed>
exactly what i'm saying, developers will continue to use absolutely positioned divs
23:28
<Clubbed>
for emulate context menus
23:28
<TabAtkins>
That's the opposite of what I just said. I said that the Google apps that *do* use custom right-click menus can migrate to using <menu> without any problem.
23:29
<Clubbed>
lol
23:30
<Hixie>
Clubbed: if your hypothesis was correct -- that is, if authors liked styling widgets so much that <menu> will fail -- then one could predict that authors would uniformly restyle scrollbars instead of using the default rendering for them
23:30
<Hixie>
Clubbed: however, that prediction does not match reality
23:30
<Clubbed>
i'm sorry but you do not understand... google wave is new, it uses custom scrollbars
23:30
<Clubbed>
so
23:30
<Hixie>
Clubbed: therefore the hypothesis is wrong
23:30
<TabAtkins>
Frex, take a look at Google Maps. Custom right-click menu. And yet, it has nothing but plain-text labels.
23:30
<Clubbed>
why did they not use os scrollbars?
23:30
<Hixie>
Clubbed: now certainly, SOME pages will make custom scrollbars and custom menus and so forth, but that's fine
23:30
<Clubbed>
it's a commercial thing
23:30
<TabAtkins>
They could swap to <menu> immediately once it was supported widely enough.
23:30
<Hixie>
Clubbed: the point is that MOST will not
23:30
<Clubbed>
exactly!
23:31
<Clubbed>
they could but they will not swap to <menu>!
23:31
<Hixie>
Clubbed: MOST pages will just use the default menu, just like they use the default scrollbar
23:31
<Clubbed>
never! they want custom design!
23:31
<Hixie>
who, the wave team?
23:32
<Clubbed>
everyone, included me
23:32
<Hixie>
so why doesn't everyone do their own scrollbars?
23:32
<Hixie>
(on a sidenote, i just hit r5000!)
23:34
<Clubbed>
just because script is hard to make
23:34
<TabAtkins>
Wave's custom scrollbars are *really weird* and very hard to use if there is a lot of overflow. I need to go complain at them.
23:35
<TabAtkins>
Clubbed: You don't need scripting to change the color of your scrollbars. IE supports some proprietary scrollbar CSS properties.
23:35
<Hixie>
yeah it's actually pretty easy to change scrollbar colorus
23:36
<Clubbed>
the point is not this, i dont want to change my context menu style or scrollbar style, never
23:36
<Clubbed>
but
23:37
<Clubbed>
i think developers dont want to be limited
23:37
<Clubbed>
come on
23:37
<Clubbed>
the web is commercial
23:37
<Clubbed>
is not a desktop app
23:37
<Clubbed>
it must be controlled but not limited
23:38
<TabAtkins>
Developers not wanting to be limited is unimportant. Does it help or harm users?
23:38
<TabAtkins>
If it harms them, then it's out.
23:39
<Hixie>
developers aren't limited here anyway, if they don't want their menus to look like native menus, they're welcome to write their own menus with script, css, and aria
23:39
<Hixie>
just like they do today
23:39
<Hixie>
the point of <menu> is specifically to let them use the default OS styles
23:39
<Hixie>
to fit in better
23:39
<TabAtkins>
And it's probably not a good idea to defend things that you don't like anyway. You can come up with much better justifications if you personally want the change you're arguing for.
23:40
<Clubbed>
hixie
23:40
<Hixie>
clubbed
23:40
<Clubbed>
if i want to use the default os style
23:40
<Clubbed>
i can use xul
23:40
<Clubbed>
embedded
23:40
<Clubbed>
with a namespace
23:40
<TabAtkins>
No you can't.
23:40
<Clubbed>
for example
23:40
<Hixie>
you can also use <menu>
23:41
<TabAtkins>
Not in HTML, at least. Maybe some browsers let you embed XUL in XHTML, I dunno.
23:41
<Clubbed>
tabatkins im using html5 as xml with xul on firefox and it works good
23:42
<Clubbed>
with xhtml dtd obviously
23:42
<TabAtkins>
I don't want to use XML. And I want my websites to work outside of Firefox.
23:43
<Clubbed>
thats not the point! xD
23:43
<Clubbed>
anyway closed discussion
23:43
<TabAtkins>
Sure it is, since you just said that the way to have OS-native context menus is to use embedded XUL.
23:45
<Clubbed>
we will talk again in... five years?
23:45
<TabAtkins>
If you're trying to change the design of <menu>, 5 years from now will be too late. ^_^
23:45
<Clubbed>
the prevision is: developers will continue to try to override default os controls
23:46
<Clubbed>
with custom divs and scripts and random shit
23:46
<TabAtkins>
I agree that some will. I think that the vast majority won't, because an OS-native display is either exactly what they want (to blend in with every other context menu the user sees on their machine) or is sufficient (because they just want the functionality, and don't care about the appearance as long as it's "good enough").
23:47
<Clubbed>
but default functionality, predefined graphics and scripting should be override-able in some cases
23:48
<Clubbed>
i dont want to customize the style of the contextmenu
23:48
<TabAtkins>
The important question is, why should they? Sometimes there are good reasons to allow such, sometimes not.
23:48
<Clubbed>
i want to put two icons for each item!
23:49
<Clubbed>
i want to put a textfield inside my toolbar
23:49
<TabAtkins>
Create a single image with both icons in it.
23:49
<Clubbed>
etc
23:49
<TabAtkins>
Or, you know, don't.
23:49
<Clubbed>
lol, just examples
23:49
<Clubbed>
title="" is limited
23:49
<Clubbed>
developers uses hidden div
23:50
<Clubbed>
to markup tooltips
23:50
<TabAtkins>
I know you can come up with examples of what someone could *possibly* do with more freedom. That's unimportant. We need to know if it's *important* to be able to do something that is currently restricted.
23:54
<Hixie>
i thought you said you didn't? <Clubbed> the point is not this, i dont want to change my context menu style or scrollbar style, never
23:54
<Hixie>
i'm confused
23:54
<Hixie>
do you want to change the style of <menu> ornot?
23:54
<Hixie>
and if you do, what is the use case
23:55
<Clubbed>
hixie, i can use html5 with no problems without styling at all and without custom labels and icons
23:56
<Clubbed>
but a lot of people will
23:56
<Clubbed>
xhtml fails for this
23:56
<Clubbed>
so
23:56
<Clubbed>
html5 should be semantic
23:56
<Clubbed>
with no limitations
23:56
<Clubbed>
for example
23:57
<Clubbed>
if html5 do <scrollbar>
23:57
<Clubbed>
developers can use <scrollbar> to customize the look
23:57
<Hixie>
the main problem i have with all that is the "a lot of people" part. What evidence do you have that it is a lot of people?
23:58
<Clubbed>
and UA can restrict by settings their styling
23:58
<Hixie>
I contend that it is not al ot of people, and i put forward as evidence the fact that not many people style their scrollbars, even though doing so is easy.
23:58
<TabAtkins>
Thus the reason why I said you shouldn't argue for things that you don't, personally, want. Arguing for other people is always fraught with peril.