00:00
<TabAtkins_>
AryehGregor: I think that a lot of them are disabled or work closely with the disabled.
00:10
<Hixie>
AryehGregor: i use text browsers often enough that for me it's actually an issue when alt text isn't good
00:11
<volkmar>
Hixie: ping
00:14
<Hixie>
pong
00:14
<Hixie>
anyone know what the mimetype for truetype fonts is?
00:15
<Philip`>
My /etc/mime.types says application/x-font-ttf
00:21
<hober>
there's no officially defined ones, IIRC
00:21
<hober>
though I've seen people pushing font/ttf, font/otf, font/eot, and font/woff lately
00:22
<volkmar>
Hixie: could i have your opinion about @autocomplete related bugs ?
00:23
<volkmar>
just to know if i should go on the direction of bug 9637 or you have a big reason to refuse
00:23
<Hixie>
given how much people push mime you'd think they would maintain the registry so that this kind of thing was easy to answer
00:23
<Hixie>
it's not like fonts are rare or something
00:24
<Hixie>
volkmar: which bug system? mozilla, webkit, w3c...?
00:24
<volkmar>
Hixie: w3c
00:25
<Hixie>
volkmar: i expect we can't change the autocomplete stuff, it's been implemented for more than a decade now
00:27
<volkmar>
Hixie: i thought autocomplete IDL attribute has been introduced with html5
00:28
<Hixie>
volkmar: IE6 didn't distinguish between IDL and content attributes
00:33
<volkmar>
Hixie: hmmm, is that really a blocker ?
00:33
<Hixie>
i dunno
00:33
<Hixie>
if we want to change it though we have to prove it's not a problem to change it, because with something that old, the safest guess is that it's impossible to change
00:34
<volkmar>
the only real difference that would happen between @autocomplete and .autocomplete is when @autocomplete is not set or set to an invalid value
00:35
<volkmar>
i doesn't sound really critic, does it ?
00:35
Hixie
points to the /topic
00:35
<volkmar>
Hixie: ok
00:36
<Hixie>
the web is a weird palce
00:36
<Hixie>
place
00:36
<Hixie>
people do all kinds of things we don't expect
00:36
<Hixie>
seriously though, unless there's a really important reason to worry about it, i would recommend not touching it
00:37
<volkmar>
Hixie: btw, who/what should use autocomplete except UAs ?
00:37
<Hixie>
how do you mean?
00:37
<Hixie>
it's most commonly used by banks
00:37
<Hixie>
google.com uses it too
00:38
<volkmar>
Hixie: sorry, i wasn't clear
00:38
<volkmar>
i mean, websites _sets_ autocomplete, the value is for the UA, right ?
00:39
<Hixie>
yes
00:39
<volkmar>
then the web shouldn't care about what .autocomplete returns
00:39
<volkmar>
... or that's still too much thinking about the wild web
00:40
<Hixie>
who knows
00:41
<Hixie>
people do crazy things
00:41
<Hixie>
often without good reason
00:56
<ttepasse>
Hm. The new reader feature in HTML 5 rearranges the hX in hgroup.
00:59
<TabAtkins_>
reader feature?
01:00
<ttepasse>
TabAtkins, like the readability-Bookmarklet: http://www.apple.com/safari/whats-new.html#reader
01:01
<TabAtkins_>
Ah, I see.
01:32
<karlcow>
you will have to love the marketing machine
01:32
<karlcow>
HTML 4.01 Support
01:32
<karlcow>
"Safari supports HTML 4.01, the authoring language that defines the structure and layout of web documents."
01:32
<karlcow>
-- http://www.apple.com/safari/features.html
01:34
<Rik`>
karlcow: the whole release feel rushed
01:34
<Rik`>
this is basically the same page as yesterday
01:35
<karlcow>
and they still didn't fix the page about html5 and web standards
01:35
<karlcow>
maybe maciej is fencing with marketing dept in Apple corridors
01:38
<karlcow>
safari 5 install 140,2 Mo of "things" and I would have to restart the computer… hmmm then later.
01:40
<karlcow>
wooot!
01:40
<AryehGregor>
Programs that make you restart the computer are lame. What are they doing, installing drivers?
01:40
<karlcow>
http://www.w3.org/TR/html5/semantics.html#the-address-element
01:41
<karlcow>
"The address element represents the contact information for its nearest article or body element ancestor."
01:41
<Rik`>
AryehGregor: updating the webkit framework
01:41
<karlcow>
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/HTMLTags.html#//apple_ref/doc/uid/30001262-SW2
01:41
<karlcow>
address
01:41
<karlcow>
Specifies a street address.
01:41
<karlcow>
????
01:42
<karlcow>
top of the document: "Safari and WebKit implement a large subset of the HTML 5 Specification defined by the World Wide Web Consortium (W3C)."
01:42
<AryehGregor>
I can do stuff like that on Linux without restarting. Just unlink the files, make the new ones, and hope that if everything gets seriously messed up the user intelligently restarts anyway.
01:42
<AryehGregor>
At least, I get the impression that's what apt-get upgrade does. Seems to work pretty well, generally.
01:42
<AryehGregor>
Of course, you've got to restart whatever programs were updated.
01:43
<karlcow>
the HTML reference of Apple is quite funky and will do a lot of bad
01:43
<karlcow>
cite
01:43
<karlcow>
Specifies a citation.
01:43
<AryehGregor>
:/
01:43
<AryehGregor>
They should just cite HTML5 verbatim.
01:46
<karlcow>
at least put a link to the spec for each element
01:47
<GPHemsley>
what does Safari 5's support for the HTML5 elements
01:47
<GPHemsley>
...consist of?
01:47
<GPHemsley>
err, lemme try that again
01:47
<GPHemsley>
what does Safari 5's support for the new HTML5 elements consist of?
01:48
<karlcow>
GPHemsley: see http://krijnhoetmer.nl/irc-logs/whatwg/20100608#l-147
01:52
<karlcow>
Apple-Specific Meta Tag Keys
01:52
<karlcow>
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/doc/uid/TP40008193-SW1
02:41
<MikeSmith>
I'm trying to write up an explanation of the motivation behind the various proposals to add a binary data type to Javascript
06:00
<boblet>
anyone know how Safari5 is implementing Reader? seems given their HTML5 sectioning element support it should use <article> if present, but it’s only using first <section> inside <article> for me
06:03
<boblet>
wonder if the article needs role="main" or something, or if it’s just broken
06:06
<ttepasse>
It uses some strange heuristics. On one site it regroups the hX inside an hgroup.
06:21
<boblet>
so much for their new! support for these elements :/
06:23
<boblet>
http://www.focus.com/images/view/11905/ “WTF is HTML5?”
06:31
<aboodman>
MikeSmith: what seems bad about magic iframe?
06:32
<aboodman>
MikeSmith: the fact that you have the same name as a PM on chromium is weirding me out.
06:33
<aboodman>
just fyi
06:39
<hsivonen>
boblet: where did they pull the readiness percentages? seems questionable that Chrome's readiness is so much higher than Safari's in particular.
06:40
<boblet>
hsivonen: small text at the bottom lists caniuse and wikipedia. I wonder if the landscape has shifted since they made it
06:41
<boblet>
bug filed for Safari Radar. I hear through the twitters that it does something wack with titles in hgroup too (yet to verify)
06:41
<boblet>
s/Safari Radar/Safari Reader/
06:42
<ttepasse>
Boblet, an example for the hgroup thingy: http://jeena.net/brother
06:44
<boblet>
ttepasse: thanks. woah, that’s bizarro
07:17
<boblet>
hsivonen: I enjoyed your http://hsivonen.iki.fi/-webkit-html5/ article. another problem is it’s hard for authors to know what vendor prefixes to add. is there a resource listing what CSS things have vendor prefixes? if not can we set a wiki up somewhere?
07:21
<boblet>
hsivonen: also you might want to mention in the conclusion that for bits of the spec that are implemented the same way using vendor prefixes by more than one browser it’s good to add the non-prefixed version too, for future support.
07:21
<boblet>
bbl
07:40
<hsivonen>
boblet: adding the non-prefixed version (which I do on my site) defeats the point of prefixes, too
07:41
<hsivonen>
boblet: since it creates a body of legacy content that assumes that standardized syntax works the same as the initial prefixed syntax
07:42
<hsivonen>
boblet: as I see it, the only real solution is to speed up the process from having two implementations to the point where the prefix is removed and the CSS WG agrees not to bikeshed the feature anymore
07:43
<hsivonen>
boblet: and to make that happen, vendors should be required to contribute sufficient editor time to the CSS WG when they come up with a CSS extension
07:43
<hsivonen>
boblet: but there's no way to enforce such a person-time contribution rule
08:23
<jgraham>
TabAtkins_: The a11y people seem to have rather different ideas about what constitues ideal alt text. For example they seem to assume that the user should be informed that there is an image, and get a description of the image. Having the page work as if there were no images in the first place doesn't seem to be a goal
08:23
<jgraham>
It would be interesting to test what is most helpful to actual users
08:30
<hsivonen>
jgraham: the "a11y people" aren't a unified "they" on this point
08:31
<jgraham>
hsivonen: Fiar enough
08:31
<jgraham>
*Fair
08:32
<MikeSmith>
hsivonen: I seem to be running into a problem with the v.nu servlet output... Is there some character limit on the length of error messages it will emit?
08:33
<hsivonen>
MikeSmith: of an individual error message? I can't recall.
08:33
<hsivonen>
MikeSmith: is this in Jetty or in Jigsaw?
08:33
<MikeSmith>
Jetty
08:34
<MikeSmith>
running locally from my workspace
08:34
<hsivonen>
MikeSmith: how does the problem manifest itself?
08:35
<MikeSmith>
hsivonen: If I validate a certain file directly from the command-line with Jing, I get the following error message:
08:35
<MikeSmith>
http://paste.plurk.com/show/267869/
08:36
<jgraham>
TabAtkins_: I'm not sure I agree it's easy either. For example I don't see the value of Hixie's alt text for the Blammo Corp example
08:36
<MikeSmith>
but if I try it with my local v.nu install, I get "error: " but with no message text
08:36
<MikeSmith>
but I do get the line number info and markup fragment
08:36
<hsivonen>
MikeSmith: and does the rest of the result page show up?
08:36
<hsivonen>
ok
08:36
<MikeSmith>
hsivonen: yeah
08:37
<Hixie>
jgraham: it's not clear to me that there's much value in making that kind of image accessible either
08:37
<hsivonen>
I'm suspecting a bug in the code that formats the message
08:37
<jgraham>
TabAtkins_: Whatever the photograph is trying to communicate, it is not "Our CEO is tall and has brown hair and a moustache"
08:37
<Hixie>
jgraham: my argument was not that my suggestion made it useful, but that it made it accessible
08:37
<MikeSmith>
hsivonen: OK, I can play around it some more and see if I can figure anything out on my own
08:37
<hsivonen>
jgraham: is that an actual alt text?
08:38
<jgraham>
hsivonen: No, it is a hypothetical one
08:38
<MikeSmith>
hsivonen: fwiw, I get no indication of a problem on the console log from v.nu
08:38
<jgraham>
Hixie: I think that is too reductionist a viewpoint
08:38
<jgraham>
I don't think you can say "is this image accessible"
08:38
<jgraham>
Only "is this content accessible"
08:38
<jgraham>
where content === whole page, typically
08:39
<Hixie>
jgraham: well that's as may be, but bruce was applying it to the figure, which is what i applied it to
08:39
<hsivonen>
jgraham: http://krijnhoetmer.nl/irc-logs/html-wg/20070927#l-332
08:40
<jgraham>
Hixie: I think my point is that the thread is trying to look at <figure>s in isolation, which is a silly thing to do
08:40
<Hixie>
jgraham: personally i'd be fine with not making the photograph accessible, since it's almost certainly purely decorative in context, but we shouldn't pretend that that means it's accessible
08:40
<Hixie>
jgraham: couldn't agree more
08:40
<jgraham>
hsivonen: Indeed
08:40
<jgraham>
:)
08:46
<Hixie>
(i'd omit the alt attribute in the case)
08:54
<boblet>
translation q: can anyone guess at what this means in English? “the pashto number in list taq” I’ve got list taq prolly being <li>, but have no idea what pashto might be
08:55
<Hixie>
Pashto is another name for the Afghani language
08:57
<boblet>
Hixie: you’re a scholar and a gentleman. will check CSS language support for list counters
08:58
<boblet>
aah GIYF (although it’s GIMF this time)
09:02
<Hixie>
boblet: wish i could claim credit... i just typed "pashto" into google and read the first hit (wikipedia) :-)
09:02
<Andros>
Semantic question: what sets a heading apart from a dt? The dt is defined as a term part of a term-description group. But isn't also a heading in a way a term, describing the content that follows it?
09:03
<Hixie>
Andros: you wouldn't put the terms of a term-description group into a book's table of contents
09:03
<Hixie>
Andros: and you wouldn't put the headings of a book into its index
09:03
<hsivonen>
Andros: the expectation is that headings appear in an outline but dts don't
09:03
<boblet>
Hixie: still drinking coffee so am apparently a little slow on the Google, but I’m now reading CSS3 Lists which you edited :)
09:03
<Hixie>
boblet: :-)
09:09
<Andros>
hsivonen & hixie: I think I see what you're meaning.
09:15
jgraham
wonders if he is the only person trying not to respond to "what is not possible in HTML5" with "faster than light travel"
09:16
<gsnedders>
But what if the bits used by HTML5 have no mass?
09:16
<Hixie>
jgraham: has that thread gotten in need of some gardening?
09:16
<Hixie>
i haven't been paying close attention...
09:16
<Hixie>
gsnedders: you'd need negative mass to get faster than light
09:16
gsnedders
is around a month behind on email
09:16
<Hixie>
(which doesn't make much sense)
09:16
<gsnedders>
Hixie: Ah, true. Duh.
09:16
Hixie
hopes he's remembering his relativity maths well enough
09:17
<gsnedders>
You are.
09:17
<gsnedders>
(I think. jgraham will now say we're both wrong.)
09:18
<jgraham>
No, once you get down to zero mass things get "interesting" but you can't travel faster than light
09:19
<jgraham>
(light itself has zero rest mass for example)
09:19
<gsnedders>
Surely it therefore also has zero relativisty mass for all values of v?
09:20
<hsivonen>
and antimatter has still positive mass?
09:20
<jgraham>
Yes
09:20
jgraham
should point out the implied "in a vacuum")
09:20
<jgraham>
(since you can travel faster than light in a non-vacuum)
09:20
<Hixie>
negative mass is basically a meaningless concept like time before the big bang, if i'm not mistaken
09:21
gsnedders
doesn't care about places apart from in a vacnuum on a frictionless bench
09:21
hsivonen
is reminded of xkdc with physicists in a frictionless vacuum
09:22
<Hixie>
that xkcd is such a lie
09:22
<Hixie>
the professor and the laptop would both more or less disintegrate if friction was zero
09:22
<gsnedders>
http://xkcd.com/669/
09:23
Hixie
notes it's basically the first hit on google for "xkdc with physicists in a frictionless vacuum" [sic], and thus not hard to find :-P
09:23
gsnedders
may have done that
09:25
<jgraham>
Hixie: I think you are assuming a particular way of changing the laws of physics
09:26
<Hixie>
a way that doesn't involve changing the laws of biology and engineering? :-)
09:27
gsnedders
notes his sister and niece have vanished
09:27
gsnedders
wonders when they'll return home
09:30
<gsnedders>
And I was expecting, the moment I said that, they come back.
09:30
<gsnedders>
It worked!
09:39
<gsnedders>
I tell my niece off for reaching for a wine bottle and now she looks scared of me.
09:46
<MikeSmith>
hsivonen: http://www.w3.org/html/check?doc=https%3A%2F%2Feyeasme.com%2FJoe%2FMathML%2FHTML5%2Fextras.xhtml&showsource=yes
09:46
<MikeSmith>
hsivonen: above shows the error-message-missing problem I was describing earlier
09:47
<hsivonen>
MikeSmith: I suggest stepping through the message formatter in a debugger
09:47
<MikeSmith>
ok
09:48
<MikeSmith>
hsivonen: bt, I notice also that the error is caused by the fact that he has an <annotation-xml> element as the first/only child of <semantics> element
09:48
<MikeSmith>
the MathML 2.0 DTD and the existing MathML 2.0 schema that v.nu is using seem to consider that valid
09:49
<MikeSmith>
but the MathML 3.0 schema and the MathML 2.0 one that I'm testing with, which is generated from that, consider it invalid
09:50
<hsivonen>
MikeSmith: parser bugs or spec bugs are possible, too, as causes for the messages
09:50
<MikeSmith>
OK
09:50
hsivonen
steps away to perform accounting rituals
09:50
<MikeSmith>
hsivonen: btw, what I have on http://www.w3.org/html/check right now is the generated MathML 2.0 schema that David Carlisle provided
09:51
gsnedders
wants a good feed reader for OS X that actually manages to resolve URLs properly
09:51
<gsnedders>
and has a simple UI.
10:20
<jgraham>
(FWIW I think that SteveF's point about the definition of <figure> is reasonable)
10:20
<jgraham>
(a figure is just a piece of content with a caption)
10:20
<Hixie>
file a bug
10:21
<Hixie>
if there's a bug
10:21
<gsnedders>
If there's a bug, file one?
10:21
<gsnedders>
Huh?
10:21
gsnedders
thinks there's some missing negative here
10:21
<Hixie>
if there's a problem, file an entry into the database
10:21
<jgraham>
gsnedders: It made sense to me
10:22
<gsnedders>
Oh, I thought you meant if there was a bug, file a duplicate.
10:22
<gsnedders>
Not if a bug exists
11:40
annevk
would have expected at least some discussion on http://www.w3.org/QA/2010/06/xhtml_modularization_a_markup.html
11:43
<jgraham>
annevk: Not sure what you would say really
11:44
<hsivonen>
annevk: It's interesting that one of the most important technologies of 2001 is only a way of writing schemas
11:44
<annevk>
anything from "joy" to "who cares" I suppose
11:45
<annevk>
but I think that blog post is a justification for them continuing to publish XHTML Modularization crap without testing it in actual user agents
11:45
<hsivonen>
annevk: sure
11:46
<annevk>
despite the problems pointed out
11:46
<hsivonen>
the timing may have something to do with the PER still being in the limbo: not publicly transitioned to REC nor rejected as a Note.
11:47
<hsivonen>
If it were clearly REC-worthy, there wouldn't be a need to post justifications like that, and the Director probably would already have approved the transition to REC.
11:52
<hsivonen>
http://lists.w3.org/Archives/Member/w3c-ac-members/2010AprJun/0049.html
11:52
<hsivonen>
(sorry about the link to secret stuff)
11:55
<annevk>
anyone here planning to go to Maastricht end of July?
11:55
<annevk>
IETF has a meeting
11:55
<annevk>
should not be too hard to plan my as-of-yet non-existing vacation plans around the meeting and attend
11:56
<hsivonen>
http://www.apple.com/safari/whats-new.html#html5
11:56
<annevk>
though I'm not too thrilled about going either (apart from visiting Maastricht, it's quite nice) as the IETF meetings I attended over the phone have been nothing but utter boredom
11:56
<hsivonen>
is there documentation on how Safari supports closed captions?
11:57
<nessy>
do they?
11:57
<Lachy>
I love how they blatantly admit that "XHTML Modularization is not [...] implemented in browsers"
11:57
<hsivonen>
nessy: claimed at the URL I just pasted
11:57
<Lachy>
(I realise that's quote mining, but still funny)
11:57
<annevk>
I suppose they support whatever closed captions H264 supports
11:57
<nessy>
I would assume it's only those that come from within MPEG-4
11:58
<nessy>
as annevk says :)
11:58
hsivonen
notes that the URL also links to the "HTML5" demos that actually demo WebKit-specific CSS features
11:58
<annevk>
nessy, I guess you're more correct, as H264 is just the video stream :)
11:59
<Lachy>
My guess is that Safari will support whatever caption formats that QuickTime supports
11:59
<nessy>
IIRC that would then be decoded by quicktime and probably rendered by quicktime, too
11:59
<Lachy>
it's kind of a shame how they're going ahead with their own caption formats now, rather than waiting for WebSRT
11:59
hsivonen
was interested in actual docs/demos
11:59
<nessy>
we should just ask Eric
12:00
<nessy>
Lachy: I don't think it covers external caption formats, so it doesn't mean anything for WebSRT
12:00
<hsivonen>
It seems that the Decision Process is useless for actually putting ISSUEs behind us and moving on.
12:02
<nessy>
what Decision Process?
12:02
<Lachy>
nessy, the HTML WG formal decision process
12:03
<nessy>
ah, I thought we were talking WHATWG
12:03
<nessy>
I do miss the email discussion of WebSRT a bit - might still be ahead of us
12:03
<Lachy>
the one that is seemingly only good at letting people drag issues on forever, despite supposedly coming to WG decisions
12:05
<annevk>
nessy, it's not finished yet
12:05
<nessy>
ah cool - I've totally lost touch in the last weeks - too busy with other stuff
12:05
<annevk>
(as in, the first draft)
12:06
jgraham
notes that the whole everything-is-HTML5 thing is the unexpectedly sour taste of victory (to quote Green Wing), so it's probably not worth getting to upset about
12:18
<Lachy>
jgraham, can it really be considered a victory when what people are referring to as being HTML5, pretty much includes everything but what acutally is HTML5, with few exceptions?
12:20
<Lachy>
HTML5 as just become the new term that replaces terms like DHTML and AJAX
12:20
<hsivonen>
Lachy: Safari 5 does better by supporting "HTML5 AJAX history" :-)
12:20
<Lachy>
haha
12:24
<Lachy>
hmm. They also claim to support article, section, etc. But they don't support the proper heading level algorithm, so that's really only a half truth.
12:24
<jgraham>
Lachy: That's not really true. We have the two biggest tech brands on the planet fighting to leverage the mindshare that HTML5 has. Compare to http://www.456bereastreet.com/archive/200705/help_keep_accessibility_and_semantics_in_html/
12:25
<jgraham>
If going from "you might be better off not using HTML5" to Apple trying to make anything and everything "HTML5" because it has such positive assosiations isn't victory I don't know what you were expecting
12:26
<jgraham>
s/Apple/Apple and Google/
12:28
<Lachy>
Sure, it's great that they're promoting HTML5, but it would be better if they would use the proper terminology for things that aren't in HTML5 instead of lumping it all together
12:28
<Philip`>
jgraham: Marketing isn't victory
12:28
<jgraham>
Lachy: Indeed. Like I said, the unepectedly sour taste of victory.
12:28
<Philip`>
I guess victory is having good technology and having lots of people use it (and marketing just helps with the latter)
12:29
<jgraham>
Philip`: On the classic scale of "First they ignore you, then they fight you, then you win", we are past "then they fight you"
12:29
<hsivonen>
jgraham: do you count XHTML-as-text/html as a victory for XML?
12:31
<jgraham>
hsivonen: Maybe a pyrrhic victory
12:31
<Philip`>
jgraham: I don't think everyone would agree with that scale - e.g. everyone who's been in a fight and then lost
12:32
<Lachy>
jgraham, I would be more comfortable calling it a victory if the things that apple were promoting as HTML5 were actually widely interoperable, rather than including things like h.264/AAC video/audio, CSS 3D Transforms, etc.
12:34
<zcorpan_>
i wonder how safari decides that a page is an 'article' and enables the Reader button
12:34
<Lachy>
and if their demos for features that are more interoperable, like WebFonts and CSS transitiosn, actually functioned in other browsers
12:35
<hsivonen>
Is Apple supporting WOFF yet?
12:35
<Rik`>
zcorpan_: apparently : http://idzr.org/ah242k
12:36
<annevk>
not many changes anymore to HTML5 based on what I had to write down for html5-diff
12:36
<hsivonen>
Rik`: is it only <div> or <article>, too?
12:37
<hsivonen>
it would be a bit sad to advertise support for <article> but not to support that feature for <article>
12:37
<Lachy>
I'm not sure. I just assumed their typography demo was using webfonts http://www.apple.com/html5/showcase/typography/
12:37
<Rik`>
hsivonen: don't know
12:37
<Lachy>
I didn't look at the source yet
12:37
<hsivonen>
Lachy: always look at the source
12:37
<Lachy>
hsivonen, that takes time
12:37
<Lachy>
I was lazy
12:37
<hsivonen>
Lachy: they have the fonts in multiple formats
12:39
hsivonen
wishes Apple added WOFF and TTF support to iOS to put make the need to use SVG fonts moot
12:40
<Lachy>
oh, interesting. They've added EOT, TTF, WOFF and SVG fonts, and yet still decided to make the demo Safari only.
12:41
hsivonen
suspects there are at least two different theys at work at Apple
12:42
<annevk>
they support EOT? oh god
12:42
<hsivonen>
annevk: in the demo
12:42
<hsivonen>
annevk: but they block IE from accessing it
12:42
<annevk>
oh, I thought to Safari
12:46
<Lachy>
have Microsoft announced which formats they will support in IE9? I assume they'll keep EOT. Will they add WOFF, TTF or OTF?
12:50
<zcorpan_>
Rik`: interesting. they claim to also support multipage articles
12:50
<Rik`>
zcorpan_: and they do. it's really well done
12:51
<Rik`>
that reminds me the fast forward feature of Opera
12:51
<Rik`>
zcorpan_: http://arstechnica.com/apple/news/2010/06/safari-5-faster-less-clutter-secure-browser-extensions.ars
12:53
<hsivonen>
whoa? you need to join a developer program to make extensions?
12:53
<hsivonen>
how different are Safari extensions from Chrome extensions?
12:54
<Rik`>
hsivonen: I'm not sure you need to join the developer program if you distribute them yourself
12:54
<hsivonen>
I guess Tiger is now clearly EOLed
12:55
<Rik`>
there is Safari 4.1 for Tiger, so not that dead
12:55
<hsivonen>
It still annoys me that Apple never says when a Mac OS X release is EOLed
12:55
<Lachy>
hsivonen, the update in that article says you can get extensions from 3rd party sites too. So no AppStore-like lock in
12:55
<hsivonen>
Rik`: whoa!
12:55
<hsivonen>
Rik`: so they now update the browser but no longer provide security patches for the OS?
12:56
<hsivonen>
is it documented anywhere that the advertised Safari features don't work on Windows unless the user chooses the Safari+QuickTime download option?
12:56
<hsivonen>
is providing the non-QuickTime download an antitrust thing?
12:57
<Lachy>
presumably, if you already have QuickTime installed, you don't need to get it again
12:57
<Rik`>
hsivonen: Safari 4.1 is apparently just an updated webkit version plus some security fixes afaict
12:58
<Rik`>
hsivonen: for Safari vs Chrome extensions http://developer.apple.com/safari/library/documentation/UserExperience/Conceptual/SafariExtensionsConversionGuide/
12:59
<hsivonen>
Rik`: thanks
13:00
<annevk>
MikeSmith, yt?
13:00
<MikeSmith>
annevk: yep
13:00
<annevk>
MikeSmith, I'm removing http://dev.w3.org/html5/html4-differences/#webarch
13:00
<annevk>
MikeSmith, the source code says you are using it, so you may want to copy it and put it somewhere safe
13:00
MikeSmith
looks
13:00
<MikeSmith>
I'm not using it anymore
13:00
<MikeSmith>
so fine by me
13:01
<annevk>
kk
13:10
<MikeSmith>
annevk: have you run the diff doc through pubrules?
13:49
<annevk>
MikeSmith, no
13:49
<MikeSmith>
ok
13:49
<annevk>
MikeSmith, I was addressing Marcos' comments
13:49
<MikeSmith>
ok
13:50
<annevk>
MikeSmith, it's not yet marked-as-WD; trying to find if I missed any comments but it seems I'm done
13:51
<MikeSmith>
when you do get to pubrules, let me know if you have any problems
13:51
<annevk>
are there any new rules or something?
13:51
<annevk>
because normally I'm automatically compliant minus a few things that are bugs in pubrules
13:54
<annevk>
ah, copyright date was wrong
13:55
<MikeSmith>
we have been having some problems with pubrules lately
13:55
<annevk>
seems someone magically fixed that while publishing
13:55
<annevk>
last time
13:55
<MikeSmith>
I might have changed that
13:55
<MikeSmith>
dunno
13:55
<annevk>
anyway, it's all good now I think
13:55
<annevk>
at least in the same state it was last time, minus the copyright bug
13:55
<annevk>
http://dev.w3.org/html5/html4-differences/
13:55
<annevk>
if people find more issues today I can probably fix them
13:56
<annevk>
and depending on when everything is moved over I can also fix things tomorrow or the date of publication
13:57
<MikeSmith>
ok
13:57
<MikeSmith>
hsivonen: I found the cause of the missing-error-message bug
13:58
<MikeSmith>
it was due to the code I added to the message emitter recently
13:58
<MikeSmith>
surprise surprise
14:01
<hsivonen>
MikeSmith: :-)
14:02
<hsivonen>
MikeSmith: I guess I suck at code review
14:02
<MikeSmith>
I think it was easy to miss
14:12
<hsivonen>
so which version of Web Sockets did Safari 5 ship?
14:18
<boblet>
hey all, re: <dl> I’ve had two ppl say today that dt/dd associations need an explicit wrapping element. one said it’s annoying to style and another said it’s hard to manipulate in Javascript. would the solution just to be make each name-value association an individual <dl>? so a description list becomes a list of multiple <dl> elements, each wrapping one name-value association
14:18
<hsivonen>
boblet: in theory that breaks semantics
14:19
<hsivonen>
boblet: Not sure whether it's a Real Problem, though.
14:19
<boblet>
hsivonen: in the styling case you’d need to apply classes to both dt and dd to style a name-value association
14:22
<boblet>
I’m guessing that we’re not able to put in eg a wrapping div to style a name-vale association (I think that’s what this means: “If a dl element contains non-whitespace text nodes, or elements other than dt and dd, then those elements or text nodes do not form part of any groups in that dl.”)
14:35
<annevk>
hmm, actually, IETF meetings are expensive
14:35
<annevk>
unless lots of friends are going to hang out in Maastricht I'm not going I think
14:41
<zcorpan_>
hsivonen: -75
14:43
<annevk>
hopefully they fix that in a .1
14:43
<jgraham>
kinda ironic given that othermaciej was instrumental in designing -76
14:50
<hsivonen>
zcorpan_: sigh. that sucks big time.
14:52
<zcorpan_>
yes
14:52
<annevk>
really?
14:53
<annevk>
Chromium dev already changed, nobody else has shipped, ...
14:54
<annevk>
and it's not like it's clear that post -75 is in a fixed state...
14:54
<annevk>
see e.g. the whole SSL handshake discussion
14:54
hsivonen
isn't reading hybi
14:54
<annevk>
prolly a smart thing
14:55
<annevk>
that was the first sensible discussion since a long time
14:55
<jgraham>
annevk: Depends if this is the same as whatever will ship on the iPhone / iPad
14:55
<jgraham>
People will make sites that sepend on those
14:55
<jgraham>
*depend
14:55
<jgraham>
Desktop Safari not si much
14:55
<jgraham>
*so
14:57
<Rik`>
I'm really concerned about the QA done with Chrome and Safari
14:58
<Rik`>
they don't mention the UI for <input type="number/date"> in the release notes which let me think it wasn't tested
15:01
<jgraham>
Rik`: It's not clar that that follows
15:01
<jgraham>
clear
15:01
<jgraham>
Sigh. I should try pressing the right keys
15:02
<Rik`>
jgraham: on http://www.apple.com/safari/whats-new.html, there are 7 lines for sectionning that adds nothing except parsing rules and display: block
15:02
<Rik`>
this was added to WebKit by Apple
15:03
<Rik`>
the new UI for forms was added by Google and there is no mention
15:03
<jgraham>
Rik`: Often QA and Marketing are not working that closely together
15:04
<Rik`>
sure
15:05
<Rik`>
but mentioning form validation and not the UI feels strange to me
15:07
<jgraham>
Rik`: Indeed. but better to test than to speculate
16:27
<TabAtkins>
jgraham: The purpose of the photograph is to provide a physical depiction of the CEO. Thus in this case a description is appropriate, as you need the caption to be referring to something (in most other cases it is purely decorative and so should receive the empty string).
16:31
<jgraham>
TabAtkins: That seems unlikely. I mean the purpose of the photograph is probably to make the company seem "more human" so stimulating a positive emotional response, or to make the CEO feel impoartant, or something
16:32
<jgraham>
it is very unlikely to be "to help the users identify the CEO in an identity parade"
16:32
<gsnedders>
Oh, is that the point of those photos?
16:32
gsnedders
have never got any point of those photos
17:34
<TabAtkins_>
Who's defining DOM 0 right now?
17:34
<jgraham>
TabAtkins: Hahahaha
17:35
<jgraham>
(that's the short answer)
17:35
<jgraham>
(the long answer is zcorpan and gsnedders worked on Web DOM Core but don't have time to pursue it, so no one)
18:50
<volkmar>
is there a reason why valueAsNumber is a double instead of a float ?
18:55
<Dashiva>
volkmar: I'd assume it's because javascript numbers are doubles
18:59
<volkmar>
Dashiva: why not but then there is a lake of consistency as progress element has only float attributes
19:00
<volkmar>
and the specs say we should apply "the rules for parsing floating point number values"
19:05
<Dashiva>
Hmm, so valueAsNumber is the only use of double?
19:05
<volkmar>
afaict
19:07
<volkmar>
Dashiva: even if it could be great to have double for progress.position
19:09
<Dashiva>
It seems valueAsNumber is used for date-based inputs, using float there wouldn't be future-proof I guess?
19:10
<Dashiva>
It used to be float, but was increased to double on request
19:13
<volkmar>
Dashiva: then, it explains why the spec say we should parse it with the float rule
19:14
<volkmar>
i suppose it should be changed if we keep float
19:14
<volkmar>
s/we keep float/you keep double/
19:53
<drclue>
OK, I switched over to Chrome 6.0.422.0 dev (Linux) to work out the new WebSocket handshake. By using injected inputs of both the link Hixie gave me http://junkyard.damowmow.com/433 and the examples in the spec , I get the expected results , but when I use the request from Chrome , Key 3 looks odd as does the result and of course it does not work. I've posted examples of the input and resulting output for all three cases at h
19:55
<AryehGregor>
drclue, cut off after "all three cases at".
19:55
<annevk>
http://hg.diveintohtml5.org/hgweb.cgi/rev/31e07449843a7982c119bc7fe2c69b595a7e46f5 -- did someone tell hsivonen? :)
19:55
<drclue>
...all three cases at http://www.drclue.net/ws.html The only thing I'm modifying in my code is the handshake , and the code did work before, and does work with the example requests, just not in Chrome. The only thing that strikes me as odd are the values for the fields "host" and "origin" , which sorta seem transposed in the request as relates to what I think I'm reading in the spec
20:03
<drclue>
In the spec it says that the "origin" request field should contain the scheme, hostname, and port , but the chrome request only has the scheme and hostname , and not the port. The "host" request field has the port tacked on the end though, and I'm not even sure that should be there
20:05
<drclue>
The only time the "origin" request field is supposed to exclude the port reference is if it is the default port, but I'm using port 10812
20:06
<drclue>
So am I just missing something obvious , or is something besides me broken here?
20:17
<jgraham>
drclue: afaict both host and origin should include non-defaul ports
20:17
<kpx>
Hey I am new to JS and I just wrote a small blog on Webstorage and HTML5 that I had studied in the past few days... Now I wanted to know some good place where I can post it so I could have some discussion and FB....
20:18
<jgraham>
The random bytes from Chrome, as written on your website look screwy
20:18
<jgraham>
kpx: I don't really understand the question
20:19
<drclue>
@jgraham I most certainly agree they look way wrong. Check out the "host" and "origin" fields in the request. Do those jive with your understanding of the spec?
20:21
<jgraham>
drclue: origin should have a port, at least
20:21
<zcorpan_>
drclue: Origin is the origin of the page which runs the script that opens the websocket
20:21
<kpx>
As in I used to submit blog entries to hacker news and all... Is there some place like taht for HTML5 and all?
20:21
<jgraham>
Ah, that's a good point
20:21
<jgraham>
If you are running the page on port 80 it shoudln't
20:22
<drclue>
@jgraham so what ya figure gives with the odd looking key 3?
20:22
<jgraham>
kpx: Not really.
20:23
<annevk>
drclue, if it's the default port of the scheme the origin production will not include the port
20:23
<annevk>
so http,80 -> no port; https,443 -> no port; http,81 -> port; etc.
20:23
<drclue>
OK, , I'm with ya on the origin
20:24
<drclue>
I still don't get this thing with the odd looking key 3.
20:24
<zcorpan_>
drclue: looks like you're converting key3 to characters
20:24
<zcorpan_>
drclue: key3 is random bytes
20:25
<zcorpan_>
drclue: don't decode them to a string
20:25
<jgraham>
zcorpan_: It looks surprisingly non-random though
20:25
<jgraham>
What am I missing
20:26
<drclue>
I understand that they are random bytes. I had only copy-n-pasted them from the shell output to the text editor where in the process they got mangled , but they were mangled looking when they came in
20:26
<jgraham>
Define "mangled looking"
20:26
<jgraham>
Were there 8 bytes?
20:27
<annevk>
opening _bytes_ in a _text_ editor doesn't really work ;)
20:27
<jgraham>
annevk: That really depends
20:27
<jgraham>
I mean they all map to something
20:27
<drclue>
Well, I'm not sure if the examples in the spec and the example in hixies example were rigged to be printable , but both of those were printable and did work in my handshake code
20:28
<annevk>
yeah, like the UTF-8 BOM followed by some stuff :p
20:28
<Hixie>
the spec examples were rigged
20:28
<Hixie>
to avoid non-printable characters
20:28
<drclue>
Yes there were the proper number of bytes
20:28
<jgraham>
drclue: So I don't understand the problem
20:29
<drclue>
The problem is that chrome won't accept the handshake
20:29
<zcorpan_>
chrome's handshake looks ok to me when i look in wireshark, and it accepts the handshake to a pywebsocket server
20:30
<Hixie>
chrome's handshake works with http://software.hixie.ch/utilities/js/websocket/ connectring to ws://damowmow.com:11111
20:30
<Hixie>
chrome 6, that is
20:30
<Hixie>
dev channel
20:30
<Hixie>
haven't tested 5.x betas
20:31
<jgraham>
drclue: You have your server code anywhere?
20:31
<jgraham>
(public)
20:31
<drclue>
It has been my assumption that the only thing I should have to change from before is the handshake and that the javascript on the browser side should go unchanged. I'm currently testing with Linux 6.0.422.0 dev
20:32
<drclue>
No , I don't have the server code up anywhere
20:33
<Hixie>
i'm pretty sure the JS should not need changing
20:33
<Hixie>
can you show us a dump of what the client sends and what the server sends?
20:34
<jgraham>
Hixie: should that page for for me? I pasted in the ws URL and hit connect but it always just disconnects
20:34
<drclue>
The only thing I'm messing with is the handshake , and for the most part I ripped off the code from http://webreflection.blogspot.com/
20:36
<Hixie>
sorry i meant ws://damowmow.com:11111/demo
20:37
<drclue>
@Hixie the closest I have to a dump is on http://www.drclue.net/ws.html examples (A) and (C) are injected , while example (B) is from chrome
20:37
<zcorpan_>
Hixie: your demo needs s/URL/url/ :)
20:37
<jgraham>
Hixie: Ah, that works :)
20:38
<Hixie>
zcorpan_: hm, yeah
20:38
<Hixie>
drclue: i would guess your problem is in handling the bytes -- you're probably converting them to UTF-8 or something
20:40
<annevk>
if we break from HTTP we should just make it a UTF-8 stream
20:44
<epeus>
anyone know if Apple did fulfil Jobs's pledge to post open specs on their new FaceTime stuff yet?
20:50
<jgraham>
epeus: I thought he promised "open standards" which is a bit different to just "open specs"
20:51
<kpx>
jgraham: Hey I wrote this small blog entry on webdatabases wanted to ask if you could just have a look and suggest some improvements... http://mnesia.wikispaces.com/HTML5+and+webstorage...
20:51
<kpx>
jgraham: thanks..
20:51
<epeus>
I saw a list fo acronyms I recognised...
21:08
<jgraham>
kpx: I haven't done a detailed technical review, but it is worth noting that the databases stuff is only really sutiable for extensions or other use cases where the target browser is known in advance
21:09
<jgraham>
because only Opera + Webkit have support and the others have rejected the idea
21:09
<kpx>
jgraham: Well i did all this while writing a chrome extension so its ok.... :)
21:11
<kpx>
jgraham: But thanks for looking, I'd be happy if you could give any pointers
21:19
<jgraham>
kpx: Yeah, I saw you were developing a chrome extension. But the second sentence of the article is somewhat misleading
21:34
<zcorpan_>
anyone wanna place bets on whether the spec will be published tomorrow?
21:34
gsnedders
realzies he can't use being under 18 as an excuse for not betting now
22:49
<nessy>
Hixie: question of process - are any of the discussions on WHATWG still useful to include new stuff into the spec or are we beyond that and changes have to be made through the W3C process?
22:52
<Hixie>
nessy: i ignore where the feedback comes from when editing the spec, so discussions on the whatwg have as much sway as discussions on the w3c side
22:53
<Hixie>
more, maybe, since the discussions on the w3c side tend to end up mired in process crap
22:53
<nessy>
excellent - was just curious
22:53
<nessy>
yeah, and politics ;)
22:53
<Dashiva>
Much the same
22:53
<Hixie>
well there's plenty of politics on the whatwg side, it's just not discussed :-)
22:53
<nessy>
which is the nice bit
22:53
<Hixie>
:-)
22:56
<volkmar>
Hixie: could we have your advice on mozilla bug 568515 (beginning to comment 3) ?
22:56
<Hixie>
looking...
22:56
<volkmar>
thanks :)
22:57
<Hixie>
wow i've no idea what i meant by "User agents must treat plaintext elements in a manner equivalent to pre elements.
22:57
<Hixie>
"
22:58
<volkmar>
oh...
22:58
<volkmar>
if it's not for the interface, what could that be ?
23:00
<zcorpan_>
i think that text was added as a result of me suggesting the spec should say what the semantics of a plaintext element are, for the purpose of e.g. speech browsers
23:01
<Hixie>
volkmar: i think it just means for semantics
23:01
<volkmar>
Hixie: then which interface should they have ?
23:01
<Hixie>
volkmar: there's a similar statement for <acronym>, saying it must match <abbr>, but <abbr> doesn't have its own interface
23:01
<Hixie>
volkmar: HTMLElement
23:01
<Hixie>
i'll file a bug on the spec to make that clearer
23:01
<volkmar>
Hixie: ok, indeed, a clarification might be good
23:02
<Hixie>
volkmar: i filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9885
23:03
<volkmar>
Hixie: thanks :)
23:06
<volkmar>
Hixie: btw, i asked earlier about valueAsNumber being a double instead of a float and Dashiva told me it was upon request
23:07
<volkmar>
but the text about the algorithm to convert a string to a number tells it has to follow the rule of parsing a floating point number which is about float and not double
23:07
<volkmar>
i suppose a clarification is needed
23:08
<Hixie>
volkmar: file another bug :-)
23:08
<Hixie>
volkmar: you can file bugs using the text box at the bottom right of the spec
23:08
<volkmar>
Hixie: i know
23:09
<volkmar>
i wanted to be sure valueAsNumber is going to stay as double
23:09
<Hixie>
no idea
23:09
<volkmar>
ok :)
23:09
<Hixie>
since JS only has one Number type, i don't know that i really care either way
23:10
<volkmar>
for the implementation, that's quite different
23:10
<volkmar>
anyway, i will file the bug
23:10
<Hixie>
thanks
23:43
<Dashiva>
volkmar: I checked the discussion from when it was changed, and it turns out float won't work at all since the timestamp is milliseconds and not seconds
23:47
<Philip`>
Dashiva: Why does the scale matter? Doesn't that just mean the maximum is 10^34 seconds, not 10^37 seconds?
23:48
<Philip`>
(so it's still plenty of ages of the universe)
23:49
<Dashiva>
Philip`: Timestamps need to be precise, so a float is pretty much a 24-bit integer in this regard
23:50
<Dashiva>
But I suppose you're right, and float would be too small even for seconds
23:51
<Philip`>
Oh, so the issue is that it has a precision of milliseconds and a range of >2^24 larger than that, rather than the issue being that it's scaled to milliseconds
23:52
<Philip`>
Things would be much easier if time didn't change so frequently
23:53
<Dashiva>
Sounds like you're onto something
23:54
<Philip`>
24fps is enough for visually smooth animation in films, so we could just quantise the universe to ~100Hz and nobody would notice
23:54
<AryehGregor>
I'm pretty sure we'd notice when chemistry stopped working. Well, actually, we wouldn't, but for entirely the wrong reason.
23:57
<Dashiva>
It seems today's date requires 31 bits for second precision, 41 for millisecond precision
23:58
<AryehGregor>
It requires 0 seconds for arbitrary precision, if you pick the start date correctly.
23:58
<AryehGregor>
It requires 0 bits for arbitrary precision, if you pick the start date correctly.
23:59
<Dashiva>
Sadly, we have a bit of a legacy environment to consider
23:59
<annevk>
oh look
23:59
<annevk>
seems we found a new issue to get all worked up about
23:59
<annevk>
the WHATWG reference