00:03
<zewt>
i've yelled at the jabber folk for their specs being a huge mass of "should" and "may"
00:03
<zewt>
total nightmare to do anything with
00:05
<zewt>
found their responsiveness to spec issues to be near-zero so i stopped bothering
00:05
<Hixie>
gavinc: "jabber:" isn't "distributed extensibility" (e.g. using dns), it's "landgrab namespacing" (what i advocate)
00:06
<zewt>
(seemed like a dead project, really, which is probably pretty much what xmpp is)
00:08
<gavinc>
Hixie: are we talking about the same thing? Jabber uses XML Namespaces
00:09
<TabAtkins>
Hixie's talking about the url protocol.
00:09
<gavinc>
aaaaahhh
00:09
<gavinc>
thank you :D
00:10
<Hixie>
actually you're both wrong :-)
00:10
<Hixie>
i'm talking about the url they use in their namespaces
00:10
<TabAtkins>
Oh!
00:10
<gavinc>
Oh!
00:10
<Hixie>
e.g. xmlns="jabber:client"
00:10
<TabAtkins>
JYNX
00:11
<Hixie>
which is pretty much exactly what i'd advocate, but nonetheless completely misses the point of distributed extensibility
00:11
<TabAtkins>
Or "jinx", rather.
00:11
<TabAtkins>
They're still going too far, imo. Their ns should just be "jabber".
00:12
<Hixie>
well they don't really need namespaces at all, imho
00:12
<Hixie>
but that's another story
00:12
<TabAtkins>
Sure.
00:12
<Hixie>
(using xml for a stream-orientated protocol is pretty nutty)
00:12
<zewt>
there are a ton of namespaces in xmpp, though, not just those
00:19
<Hixie>
in other news, this table has had me as its bitch all day and i have only finally defeated it. http://www.whatwg.org/specs/web-apps/current-work/#autofill-field
00:21
<Hixie>
btw if there are any chrome qa people around who want something to do, the "M" in the "Mlle" example in that table is vertically aligned incorrectly
00:21
<Hixie>
i've been unable to determine why, but haven't looked closely
01:03
<jamesr_>
Hixie, what platform are you seeing bad alignment on?
01:03
<jamesr_>
you mean the "M<sup>lle</sup?" entry, right?
01:11
<Hixie>
jamesr_: mac and yes
01:11
<Hixie>
jamesr_: dev branch chrome
01:13
<jamesr_>
ah i see it now - it's a bit lower than it should be, right?
01:55
<gavinc>
ugh, balancing change/new features and doing what already works is very annoying.
06:35
<MikeSmith>
hsivonen: I wonder if the < 1 validations per second data you're seeing is due to the server hardware
06:36
<MikeSmith>
I'm seeing more like 1.9 validations per second
06:41
<hsivonen>
MikeSmith: unlikely. e.g. validating the front page of my site takes 44 milliseconds
06:41
<hsivonen>
MikeSmith: and the server is configured for concurrency
06:42
<MikeSmith>
OK
06:42
<hsivonen>
also, the CPU load is very low
06:43
<MikeSmith>
hsivonen: well we have some fairly beefy hardware behind the W3C service, and the data is pretty consistent across the majority of the hosts
06:43
<MikeSmith>
hsivonen: OK
06:43
<MikeSmith>
anyway, the W3C stats show those hosts consistently doing about 1.9 validations per second
06:44
<MikeSmith>
based on roughly 115,000 validations so for
06:44
<MikeSmith>
0.71 days
06:45
<hsivonen>
ok
06:46
<hsivonen>
the *completely* unused features so far: XHTML output, SVG schema, custom Schematron
06:48
<MikeSmith>
yeah that's as expected I guess
06:48
<hsivonen>
I expected someone to validate an occasional SVG file
06:48
<hsivonen>
I expected the legacy XHTML+SVG+MathML schema to be used less than the SVG schema
06:49
<MikeSmith>
OK
06:49
<shepazu>
I'm surprised that nobody's tried to validate SVG… is that what you're saying?
06:49
<hsivonen>
as for HTML vs. XML input, HTML is more than 99%
06:49
<hsivonen>
(Occupy XML)
06:49
<hsivonen>
shepazu: yes
06:49
<shepazu>
huh!
06:49
<MikeSmith>
shepazu: raw data is here: http://validator.nu/stats.html
06:50
<hsivonen>
and http://html5.validator.nu/stats.html
06:50
<shepazu>
oh, I believe you… I just went for years without an SVG validator, I never got in the habit myself (I just used XML validation when needed)
06:51
<shepazu>
9K validations doesn't seem like much… what time period, out of curiosity?
06:52
<hsivonen>
shepazu: see "Uptime in days" (which is < 1)
06:53
<shepazu>
oh
07:24
<hsivonen>
Underspecified feature request is underspecified: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18439
07:32
<rniwa>
hsivonen: i can't even comprehend that sentence :(
07:32
<rniwa>
that is… the bug title.
07:57
<MikeSmith>
hsivonen: I don't know if you noticed yet but the settings for the filter feature of http://validator.keegan.st/ are persistent
07:59
<MikeSmith>
as in, once you filter out a certain class of errors, it's going to filter those out for you automatically from then on
08:04
<hsivonen>
I should pay more attention to the validator diagnostics. V.nu has been crashing due to an NPE that MikeSmith fixed over a month ago, because I had failed to redeploy after the fix
08:04
<MikeSmith>
damn
08:04
<MikeSmith>
sorry man
10:04
<hoolter1>
are opening and closing <html> tags required?
10:05
<hoolter1>
or are they implicit?
10:06
<jgraham>
Impolicit
10:06
<jgraham>
*Implicit
10:06
<hoolter1>
jgraham: cool.
10:07
<hoolter1>
jgraham: but then how can one specify doc language?
10:07
<hoolter1>
jgraham: any way?
10:09
<hoolter1>
iis it possible to read a file that your user DnD'd, then have the user open said file in, say, notepad, modify + save the file, and then for you to read the new changes without the user having to re-DnD the file again?
10:30
<hsivonen>
MikeSmith: it was my fault I didn't pay attention to diagnostics. the HTTP client had spammed me enough that it had taught me not to take the log4j emails too seriously :-(
10:30
<hsivonen>
MikeSmith: I guess I should upgrade to HttpClient 4.1
10:30
<hsivonen>
turns out the API has changed
10:31
<hsivonen>
not just a matter of changing package names
10:48
<AryehGregor>
hoolter, "doc language"?
10:49
<AryehGregor>
hoolter, for the latter question -- probably not. That sounds like it would be a security vulnerability.
10:49
<AryehGregor>
Although maybe you can, I don't know.
10:49
<AryehGregor>
I take that back, yeah.
10:49
<AryehGregor>
I doubt browsers copy the file.
10:49
<AryehGregor>
Dunno how it works.
10:50
<AryehGregor>
What API are you using to read the file?
11:19
<hoolter>
AryehGregor: i've heard probably yes and probably no but i'm looking for someone who could tellme for sure.
11:19
<hoolter>
and i meant <html lang=en>
11:19
<AryehGregor>
hoolter, well, you can't omit the root tag if you want to specify any attributes on it. You can still omit the end tag.
11:20
<AryehGregor>
If you want lang=en on the root element, you can't omit <html>, no.
11:20
<AryehGregor>
You could put it on <body>, although then you can't omit <body>.
11:20
<AryehGregor>
hoolter, with respect to the file question: what API are you using to read the file?
11:32
<hoolter>
AryehGregor: so I can have the following as my entire file and it's all totally fine then? | <!doctype html><html lang=en><meta charset=utf-8><title>t</title><p>hello, world!</p>
11:33
<hoolter>
AryehGregor: IDK. I'm just wondering if it's possible at all. See this video... just watch the first 25s of it or so, it's incredible. but i can't reproduce it or wrap my mind around how it could work. you know? www.youtube.com/watch?v=mY56fNmn2cE&feature=player_embedded
11:34
<AryehGregor>
hoolter, yes, that's valid. Enter it into http://html5.validator.nu/ and see for yourself. The shortest valid HTML document is: <!doctype html><title></title>
11:38
<hoolter>
AryehGregor: sweet. do u mind checking the video? It is fairly cool regardless of my question.
11:39
<AryehGregor>
hoolter, I have other things I'm doing right now. If you have specific questions beyond what you've already asked, feel free to ask.
11:39
<hsivonen>
Now I remember why I went upgraded to HttpClient 4.1 yet. It's even more complicated to use than 3.1.
11:39
<hsivonen>
s/went/haven't/
11:50
<hoolter1>
AryehGregor: well i mean, is what i described possible using any api whatsoever that's thus yet been implemented by a version of chromium?
11:50
<AryehGregor>
hoolter1, 1) I don't know offhand, 2) what does Chromium have to do with it? This is a standards channel.
11:57
<hoolter>
AryehGregor: well that's the one that was used to demo the feature in the video. presumably it's at least a proposed standard of some sort.
11:57
<AryehGregor>
Probably.
11:57
<AryehGregor>
There are various file-related APIs floating around, I haven't been keeping track.
12:09
<hoolter>
AryehGregor: ah, ok.
12:12
<smaug____>
hoolter: yes, chrome implements some file system APIs
12:12
<smaug____>
I don't think anyone else is going to implement those APIs
12:13
<smaug____>
(but there will be some other file handling related APIs )
14:55
<zewt>
heh alt/title thread going on right when i hit a curious bit of nonsense
14:56
<zewt>
http://valgrind.org/docs/manual/dist.news.html has title="2. NEWS" on the whole thing, which apparently means that no matter where I idle the mouse, a "2. NEWS" tooltip pops up
14:56
<zewt>
(in Chrome, anyway)
15:02
<zewt>
now, if @title had simply been named @tooltip, nobody would be getting confused and thinking @title means something like "title for this section", heh
15:02
<zewt>
("but it might be displayed as something other than a tooltip!" ... that doesn't matter! heh)
15:02
<odinho>
heh. People.
15:03
<jgraham>
Maybe it shoudl have been named @banana
15:04
<zewt>
(because that would have been informative)
15:06
<jgraham>
Well it would stop people reading things into the name
15:06
<zewt>
reading things into the name is fine, if it's at least the right ballpark
15:12
<karlcow>
@hint ?
15:13
<zewt>
not like we can change it :)
15:13
<karlcow>
we can… it depends on the choices of life ;) being compatible or not with the deployed Web.
15:14
<karlcow>
being irrelevant as an art of life.
15:16
<zewt>
well, we already know the answer to that, heh
15:45
<Stevef>
some examples of title duplicating text content http://www.html5accessibility.com/tests/title-usage.html
16:02
<jgraham>
Hixie: Was there some change recently to the spec regarding pushState and base URLs? I (think I) remember you mentioning it, but I can't find it right now
16:06
<jgraham>
Ah http://krijnhoetmer.nl/irc-logs/whatwg/20120629#l-110
16:08
<Hixie>
jgraham: for some definition of "recently", yes
16:08
<Hixie>
jgraham: basically the concept of "current document's address" is entirely removed
16:08
<Hixie>
jgraham: it's a pretty big simplification
16:09
<Hixie>
jgraham: (unfortunately seems to screw opera for following the spec, sorry about that)
16:10
<jgraham>
Hixie: Well a month ago is pretty recently
16:10
<Hixie>
k :-)
16:11
<jgraham>
Well I was away for 2.5 weeks of that time as well :p
16:11
<jgraham>
So what's an observable change here?
16:12
<Hixie>
let me get you a test case, one sec
16:12
<Hixie>
http://hixie.ch/tests/adhoc/dom/level0/history/pushState/
16:12
<Hixie>
warning, these tests seriously confuse the back button
16:13
<jgraham>
Great, thanks
16:13
<jgraham>
Heh
16:50
<dglazkov>
good morning, Whatwg!
16:50
<edwardbc>
morning
16:51
<Hixie>
ok, i've added examples to the autocomplete field table. yay for timbl whose name has all the needed fields. :-)
17:12
<zewt>
a new (gross) one to me: someone sending mail with code in it ... with syntax highlighting
18:13
<hober>
Hixie: nope
18:24
<Hixie>
hober: k
18:49
<Hixie>
zewt: yt?
18:49
<Hixie>
zewt: re http://www.w3.org/mid/CABirCh-3Fa6xH=JA_j1b=d-7fGfrhAiG8WFUr=zbx0HDBGqEkQ⊙mgc -- what do you mean by "header line"?
19:10
<zewt>
Hixie: a line eaten by the "Header" section of the parser
19:11
<Hixie>
do you mean that this:
19:11
<Hixie>
WEBVTT
19:11
<Hixie>
language:fr
19:11
<Hixie>
timestamp --> timestamp
19:11
<Hixie>
foo
19:11
<Hixie>
...would treat "language:fr" as a "header" line?
19:11
<Hixie>
rather than as an "id" line?
19:11
<zewt>
yes, though it looks correct in that instance
19:11
<Hixie>
ok
19:12
<Hixie>
RESOLVED Working As Intended
19:12
<Hixie>
:-)
19:12
<zewt>
i mean if the "language:fr" line was actually something meant to be a "text track cue identifier", eg. step 31
19:13
<Hixie>
well the file is non-conforming either way
19:13
<Hixie>
this is just error handling
19:13
<Hixie>
for all we know, the line in question could be the cue text from some previous cue whose timestamp got croped
19:13
<Hixie>
cropped
19:13
<zewt>
huh? webvtt cue identifiers are in the syntax
19:14
<Hixie>
or it could be that the --> line is actually meant to be a comment
19:14
<Hixie>
the point is the file is invalid, so there's no way to know what the author meant
19:14
<Hixie>
we're just doing our best to salvage what we can from the mess
19:14
<zewt>
okay, looking at the syntax, the correct answer is "there should be a blank line before the first cue"
19:18
<Hixie>
right
19:19
<zewt>
(followed up on the thread to close that out)
19:21
<zewt>
(guessing that'll be a common mistake, but probably a harmless one since cue ids are probably uncommon)
20:04
<Areks|2>
Hello all.
20:06
<Areks|2>
Who made markup for tablet with android?
20:08
<Areks|2>
I use "Times New Roman" font in design, and all devices display it correctly except android.
20:09
<Areks|2>
Does anybody had same problem?
20:11
<Wilto>
Areks|2: Some older Androids will default to Droid Serif for all serifs and Droid Sans for all sans-serifs. It may not have Times New Roman installed.
20:12
<Wilto>
The #CSS channel is a more appropriate place for these sorts of questions -- hope that helps, though.
20:14
<Areks|2>
Wilto: The problem is really interesting, because cyrillic symbols display correctly
20:15
<Areks|2>
Wilto: i'll try to ask on css, thanks
20:15
<Wilto>
No worries, man.