00:00
<Hixie>
annevk2: for file upload i'm waiting for arun's draft
00:01
<ap>
Hixie: the spec says that WebSocket is to app-level protocols what TCP is to internet protocols
00:01
<ap>
Hixie: if you're targeting TTY instead of TCP, please say so :)
00:02
<ap>
Hixie: so yes, send() can of course return how much space there's in UA queue at the moment (I was thinking about kernel queue, and this data is usually unavailable)
00:02
<ap>
Hixie: it feels quite weird to report implementation details in this way though
00:03
<annevk2>
it should probably be a percentage or something as otherwise you need to figure out UTF-16 vs UTF-8 etc.
00:03
<annevk2>
if anything at all, that is
00:05
<ap>
the important thing is to be able to estimate the available bandwidth, and keep the UA queue close to empty after that
00:05
<ap>
or take 50% of available bandwidth, for example
00:06
<Hixie>
ok so i got run of onoverflow, and instead just made send() return a number, which is either 0 (connection closed), 1 (buffering not supported), a number indicating the number of bytes that can be buffered, or 4294967295 if the buffering is essentially unlimited.
00:06
<Hixie>
and overflowing the buffer closes the connection.
00:07
<Hixie>
got rid of, rather
00:08
<franksalim>
i'm catching up on the mailing list thread. has the alternative been discussed in which notification occurs when writes are successful? this would allow application code to make use of an arbitrarily large buffer but be aware of the rate at which the buffer is being drained
00:08
<ap>
Hixie: what is the client to do when 1 is returned?
00:08
<Hixie>
ap: pray it doesn't hit the network rate limit
00:09
<Hixie>
ap: i just needed a number that wasn't 0, since 0 means "failed"
00:09
<ap>
Hixie: ok
00:09
<ap>
Hixie: I think that's workable, let's see what people have to say about elegance
00:10
<Hixie>
it's the web, i gave up trying to win any awards for legance long ago :-)
00:10
<Hixie>
but yeah
00:10
<Hixie>
for elegance, even
00:10
<ap>
franksalim: could you explain this in more detail? what's a successful write?
00:10
<franksalim>
ap, successfully dequeued by the UA
00:10
<franksalim>
ap, not necessarily acked
00:11
<ap>
franksalim: I see. I don't think it's been suggested
00:11
<franksalim>
this would make the information available to keep buffers close to empty for "smart" developers, but not close connections forcefully at arbitrary limits
00:12
<roc>
what was wrong with my idea of allowing apps to query the amount of buffered data?
00:12
<Hixie>
roc: that's basically what we have now, though in reverse
00:12
<franksalim>
most (all?) other js APIs can use arbitrarily large amounts of memory
00:13
<Hixie>
maybe we should also have an attribute for the actual amount pending?
00:13
<franksalim>
Hixie, roc: except what we have now implies that there has to be a max, right?
00:13
<ap>
franksalim: I think that a highwater mark notification would still be needed to rate limit
00:13
<Hixie>
franksalim: no, the UA is allowed to return 4294967295 if the buffering is essentially unlimited
00:13
<franksalim>
Hixie, but then you don't know how much of the buffer you have used
00:13
<Hixie>
franksalim: correct
00:14
<roc>
I think it's a lot more useful to know how much data is queued than how much space is left in the buffer
00:14
<franksalim>
i think it is desirable to have an unlimited buffer size with the ability to know how large a buffer you are using
00:14
<franksalim>
roc, i agree
00:14
<Hixie>
hmm... maybe i should have it return the amount queued, then? or make it return a boolean and have a separate amount-queued attribute?
00:14
<ap>
franksalim: "other js APIs can use arbitrarily large amounts of memory" - the issue here is not with OOM, but with letting the app achieve its mission. other JS APIs don't usually cause infinite memory growth when doing something useful
00:15
<Hixie>
roc: what should i call such an attribute?
00:15
<franksalim>
ap, yes. but setting a max buffer size is not necessary. the important data is how far backed up you are, not how much space you have left
00:15
<Hixie>
websocket.queueLength?
00:15
<roc>
bufferedAmount?
00:15
<ap>
franksalim: agreed
00:18
<ap>
Hixie: with the boolean returned, will it be for success/failure?
00:18
<Hixie>
it'll return false if the connection is closed (e.g. because of buffer overflow) and true otherwise
00:19
<Hixie>
roc: once the connection is closed, should bufferedAmount be reset to zero, or should it continue counting the number of bytes that aren't getting sent?
00:24
<Hixie>
this attributes makes a lot of sense, it lets you just check to see if it's non-zero, and just not send data while that is true
00:25
<ap>
Hixie: it will still take a good amount of "isSafari" and "isFirefox" checks for someone to send a 128K blob of data
00:25
<Hixie>
why?
00:26
<ap>
Hixie: maybe I'm just not seeing how it can be done. what would you suggest?
00:27
<ap>
for a browser that can buffer such amount, the best way is to send in one chunk
00:27
<roc>
Hixie: I'd say bufferedAmount should keep increasing, if you keep allowing send()s
00:27
<ap>
for one that cannot - how large can bufferedAmount become before the app should freak out?
00:28
<Hixie>
roc: k, done that
00:28
<Hixie>
ap: if you're sending a 128KB frame, then it's one send() call.
00:28
<roc>
ap: I think this is just like any other memory issue
00:29
<Hixie>
ap: so there's nothing to check
00:29
<ap>
roc: if I understand what you're saying right, the model is that buffer will be unlimited (or huge) for this API to work
00:29
<roc>
right
00:29
<roc>
which is like all the other buffers Web apps deal with today
00:29
<ap>
roc: makes sense
00:30
<roc>
I think in practice if you carve your data into 1MB chunks you should be in good shape for any scenario
00:30
<ap>
other than dial-up :)
00:30
<roc>
then you're just doomed :-)
01:05
<Tripler>
Can anyone point me in the direction of a tutorial for the <video> tag and how to style etc
09:07
<Philip`>
"return the result of subtracting value from zero" - hmm, sounds like COBOL
09:09
<annevk4>
"the Hixie fork of the HTML5 specification" classic
09:11
<othermaciej>
annevk4: Hixie was just tired of Hixie's unsound, dictatorial decisions
09:11
<othermaciej>
annevk4: so he had to fork Hixie's original spec and make his own
09:17
<annevk4>
zcorpan, really? you want a section on SGML differences?
09:17
<annevk4>
zcorpan, nobody cares
09:18
<annevk4>
fortunately both objections placed so far are against process and I don't think they carry any weight
09:18
<annevk4>
well, "fortunately" I personally don't really care that much about publishing either way I think
09:23
<othermaciej>
I don't think Working Drafts are all that important, but I do get annoyed at every little thing being turned into a political fight
09:23
<othermaciej>
in particular, the Editor's Draft being mch changed from the Working Draft was used for political point scoring
09:23
<othermaciej>
and now the process of updating it is being turned into a political fight
09:24
<zcorpan>
annevk2: i was more thinking of extending the paragraph with more examples
09:24
<zcorpan>
"... such as NET syntax, marked sections and processing instructions"
09:25
<annevk4>
marked sections?
09:25
<annevk4>
I suppose I could add something like that
09:25
<zcorpan>
<![INCLUDE[ ]]>, <![CDATA[ ]]>
09:26
<annevk4>
well, <![CDATA[ ]]> is still there somewhat
09:26
<zcorpan>
true
09:26
<zcorpan>
maybe don't mention marked sections
09:49
<annevk4>
joy, co-author of URI and IRI specs wonders whether www.%77%33.org vs www.w3.org is a problem
11:12
<gsnedders>
Hixie: yt?
11:32
<gsnedders>
Hixie: Ignore that
12:15
<gsnedders>
Why would html5lib.HTMLParser().parseFragment(StringIO("<p>foo")) return None
13:10
<Lachy>
Philip`, do you have, or could you obtain, any data comparing how common it is for authors to include = within unquoted attribute values, compared with those that write attributes like alt= with no value?
13:10
<Lachy>
I'm trying to show why Hixie choice is wrong here http://lists.w3.org/Archives/Public/public-html/2009Jul/0817.html
13:23
<Dashiva>
What's the reason a= and a=b=c can't both be valid? I can't remember. Is it stuff like a=b c?
13:25
<Lachy>
Dashiva, Hixie claims it's because of situations like <img alt= class=photo> where "class=photo" would be interpreted as the value of the alt attribute
13:27
<Dashiva>
If the space between them was left out, you mean?
13:27
<Lachy>
no, with the space
13:27
<Lachy>
perhaps the better solution is to make whitespace before unqutoed attribute values invalid
13:28
<Dashiva>
Oh. So there's probably content that depends on a= b being parsed as a="b" then
13:28
<Lachy>
so <img class= photo> would be invalid, but <img class= "photo" could still be valid
13:28
<Lachy>
yes
13:38
<Philip`>
Lachy: How would those two cases be distinguished? <img alt = class=photo> seems like it could be either, and would require human interpretation
13:39
<Philip`>
Lachy: But anyway I don't have data like that, and don't think I can easily obtain it, since it probably involves hacking the tokeniser
13:42
<Lachy>
Philip`, you could use a rough technique by looking for obvious cases like the href attribute where = in values is common <a href= ?foo-bar>, and also look for [^=]+=\s+([A-Za-z]+)= where $1 matches known attribute names
13:42
<Lachy>
s/foo-bar/foo=bar/
13:43
<Lachy>
actually, just the regex would be more like [A-Za-z]+=\s+([A-Za-z]+)=
13:44
<Lachy>
or [A-Za-z]+\s?=\s+([A-Za-z]+)=
13:48
<gsnedders>
Philip`: Can you fix html5lib so test cases can run with more recent SimpleJSON which throws on "output":["ParseError", ["Character", "\uD869"], "ParseError", ["Character", "\uDED6"]]}?
14:15
<Philip`>
Lachy: Hmm, that sounds kind of vague :-p
14:16
<Philip`>
If you have a single specific Java-compatible regexp, I can run it and give a list of the matching lines or of matching substrings
14:16
<Philip`>
and then I wouldn't have to actively think about it, which would be good
14:16
<Philip`>
gsnedders: Why me? :-(
14:16
<Philip`>
gsnedders: Also: How could it be fixed?
14:16
<Lachy>
ok, I'll have to find out what a java compatible regex is, and how it differs from the one I gave you
14:17
<gsnedders>
Philip`: Because your around, and might have an idea of how to fix it.
14:17
<Philip`>
Lachy: It's basically a Perl-compatible regexp
14:17
<Lachy>
is the one I gave you perl compatible?
14:17
<Philip`>
so the one you said should be fine
14:17
<Lachy>
except for the mistake in it
14:17
<Philip`>
but you'd need to include the list of common attribute values if that's what you want
14:17
<Philip`>
Uh, names
14:18
<Lachy>
corrected version: [A-Za-z]+\s*=\s+([A-Za-z]+)=
14:19
<Philip`>
gsnedders: Hmm, what test case can cause the expected output to have unpaired surrogate codepoints?
14:19
<Lachy>
do you mean like: [A-Za-z]+\s*=\s+(class|href|src|...)=
14:19
<Philip`>
Lachy: Yes
14:19
<Lachy>
ok
14:19
<Philip`>
Lachy: if you want to restrict it to that
14:19
<gsnedders>
Philip`: A tokenizer one with input like that
14:19
<Philip`>
Lachy: (Also you might want to prefix with (?i) to make it case-insensitive)
14:19
<gsnedders>
Philip`: From your script, I think
14:19
<Philip`>
gsnedders: Yes, but I'm too lazy to look it up myself :-p
14:21
<Lachy>
ok, I'll think about it more and get back to you
14:24
Philip`
ought to set up a web service so people can run their own regexps over the page data
14:24
<Philip`>
(but that sounds like too much effort now)
14:27
<Lachy>
how much processing time does it take to run a typical regex over the data?
14:29
<Philip`>
Um... A while
14:30
<Lachy>
like a few hours?
14:30
<Philip`>
(so a web service would have to be restricted to a subset of the data most of the time)
14:30
<Philip`>
More like a few minutes
14:30
<Philip`>
(for the 425K pages)
14:30
<Philip`>
where "few" might be "ten" or something but I can't really remember now
14:30
<gsnedders>
yay! An IndexError from html5lib. What I always wanted.
14:30
<Philip`>
and also it depends on the complexity of the regexp
14:30
<Lachy>
ok. Still, it would be a DOS risk
14:31
Lachy
would abuse the system by trying to run hundreds of simultaneous queries for the same thing :-)
14:31
<Philip`>
It's fast enough that I haven't bothered writing the code to parallelise it, in any case
14:32
<Philip`>
There's also the issue that the university wouldn't be particularly happy about running web servers on their machines, for security
14:33
<gsnedders>
fragment parsing isn't well tested in html5lib seemingly
14:37
<annevk>
gsnedders, yeah, it wasn't well implemented either iirc
14:37
<annevk>
at least not initially
14:38
gsnedders
has so far hit one exception and one infinite loop
14:44
<gsnedders>
Oh, wait.
14:44
<gsnedders>
This infinite loop isn't an html5lib bug. We follow the spec. The spec has an infinite loop.
14:45
<gsnedders>
I guess this is where we're allowed implementation specific limitations, due to hardware constraints.
14:45
<annevk>
the spec has an infinite loop?
14:45
<annevk>
and validator.nu does not?
14:47
<gsnedders>
annevk: validator.nu doesn't implement innerHTML, does it?
14:51
<annevk>
I thought it did
14:59
<annevk>
yeah, that's loop indeed
14:59
<Philip`>
gsnedders: Any self-respecting Turing-complete machine should be happy to run infinite loops without exceeding hardware constraints
15:00
<gsnedders>
True, but they never complete executing, which annoys me.
15:00
<Philip`>
The desire to not wait infinitely long for a web page to render is a user constraint, not a hardware constraint
15:00
<Philip`>
and we should consider other solutions to that problem, such as making users immortal
15:03
<gsnedders>
Philip`: Do you know of anyone who will implement that?
15:04
<Philip`>
gsnedders: No, but I can think of a number of ways to test it
15:08
<gsnedders>
Can anyone see a better fix for the middle change in http://code.google.com/p/html5lib/source/detail?r=21ce65db1e551ef8e7c4e91db0295caab08a4f62#
15:15
<Philip`>
gsnedders: for e in reversed(self.tree.openElements): if e.name == 'table': return e; (newline) return self.tree.openElements[0]
15:15
<Philip`>
perhaps?
15:16
<Philip`>
(except not using reversed if we want Python 2.3 compatibility)
15:17
<Philip`>
The code you checked in looks disgusting :-p
15:34
<gsnedders>
Philip`: Agreed, but I was going it off the top of my head :P
15:34
<Philip`>
"This is such an extreme edge case that I'm surprised this discussion has received 34 (now 35) replies." - someone should teach him about bikesheds until it no longer surprises him
15:35
<Philip`>
gsnedders: I think it's best if you use the insides of your head instead :-p
15:35
<gsnedders>
Philip`: Where is this?
15:37
<Philip`>
gsnedders: Between your shoulders and your hair
15:38
<gsnedders>
Philip`: No, the quote
15:39
<Philip`>
gsnedders: Oh, on the PHP/SGML discussion
15:40
<ezyang>
Does HTML5 do anything special to &image inside URLs?
15:41
<gsnedders>
ezyang: no
15:41
<ezyang>
hmm, ok
15:43
<Philip`>
&image; is special, though
15:46
<ezyang>
oh, wow, so browsers will interpret &image= as the actual character entity. News to me.
15:46
<Philip`>
No, only &image;=
15:47
<Philip`>
(Well, or &image;foo or whatever)
15:47
<ezyang>
Wait, really?
15:48
<ezyang>
If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON (;), and the next character is in the range U+0030 DIGIT ZERO to U+0039 DIGIT NINE, U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, or U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND (&) must be unconsumed,
15:48
<Philip`>
Only the ones explicitly listed (in the giant table in HTML5) without a semicolon will be parsed if they don't have a semicolon
15:48
<ezyang>
aha!
15:48
<Philip`>
and then only in cases where they're not followed by 0-9a-z
15:49
<Philip`>
so &amp=foo is an entity, &ampx=foo isn't, &image=foo isn't, &image;=foo is
15:49
<Philip`>
(if I remember correctly)
15:49
<Philip`>
(in attribute values)
16:17
<dbaron>
othermaciej, We've had conference room names for less than 24 hours and you already know that they're good?
16:23
<mengelhardt>
Hello
17:25
<jacobolus>
Hixie: I remember you data-mined a big corpus of pages to figure out common class/id names. Has anyone done similar for frequency of font names used in css?
17:26
<jacobolus>
or are there big page sets already gathered (and freely available somewhere?) to do such an analysis on?
17:28
<Philip`>
jacobolus: There's http://dev.opera.com/articles/view/mama/ but I'm not sure that's got font names
17:29
<Philip`>
That uses pages downloaded from the freely available list from dmoz.org
17:29
<Philip`>
http://www.dotnetdotcom.org/ has a big pile of HTML pages (no CSS) freely available
17:29
<jacobolus>
Philip`: thanks, that's a cool resource. no listed fonts though
17:30
<jacobolus>
(the opera one)
17:30
<tantek>
are there actually authors that try to validate (unprocessed source) PHP files as HTML?
17:31
<Philip`>
jacobolus: I can easily run regexps over dotnetdotcom's ~425K HTML pages, so if there's a regexp that would (approximately) extract font names (from inline CSS) then I could do that
17:32
<jacobolus>
Philip`: okay, just a minute
17:33
<takkaria>
"font\s*:" and "font-family\s?:" would probably catch a lot them
17:34
<Philip`>
(?i)font(?:-family)?\s*:([^;"}]+) gives some stuff you could extract individual names from
17:38
<jacobolus>
Philip`: will your regexps just return all captures?
17:39
<Philip`>
jacobolus: For each line that matches the regexp, it can either print the line or print the first matching substring or print any captured group
17:40
<jacobolus>
just one of the captured groups?
17:40
<jacobolus>
oh, I guess if it can print the lines out, it would be possible to grab that and run further regexps on it
17:40
<Philip`>
Yes
17:41
<Philip`>
Most of the lines have lots of HTML junk in them
17:46
<jacobolus>
yeah
17:46
<Philip`>
jacobolus: http://philip.html5.org/data/fonts-in-inline-css-raw.txt.gz (~7MB) has the strings that match the regexp I gave earlier
17:47
<jacobolus>
font(?:\-family)?\s*\:.*\s*((?:(?:'[a-zA-Z ]*')|(?:"[a-zA-Z ]*")|[a-zA-Z]*)(?=\s*[,}])[^}]*)}
17:47
<Philip`>
(I can do it differently if you're willing to wait ten minutes for it to regenerate)
17:47
<jacobolus>
I think that should be right
17:47
<jacobolus>
I should do some testing
17:47
<Philip`>
(Use a command like 'gzip -cd fonts-in-inline-css-raw.txt.gz|sort -u|cut -f2|sort|uniq -c|sort -n' to count number of pages each string occurs on, etc)
17:49
<jacobolus>
actually
17:49
<jacobolus>
font(?:\-family)?\s*\:.*\s*((?:(?:'[a-zA-Z ]*')|(?:"[a-zA-Z ]*")|[a-zA-Z]*)(?=\s*[,;}])[^;}]*)[};]
17:49
<Philip`>
jacobolus: That seems like it's probably close to a subset of what my regexp was matching, so hopefully you could just run that on my existing output :-)
17:50
<jacobolus>
Philip`: probably a subset, yes :)
17:50
<jacobolus>
this just grabs all the fonts in a "stack"
17:50
<jacobolus>
as one capture
17:50
<Philip`>
jacobolus: That one wouldn't match style="font-family: wingdings"
17:50
<Philip`>
I think
17:50
<jacobolus>
oh, true
17:50
<jacobolus>
because it doesn't end in ,, ;, or }
17:51
<jacobolus>
:/
17:53
<Darxus>
I suppose I should complain about the inability to set an li style to "+" or "-" to the css folks, not the html folks?
17:55
<Darxus>
Sorry, nevermind: 12:56PM < mamont> Darxus: li:before { content: "+"; }
17:55
<jacobolus>
Darxus: you can just use a custom image or so, no?
17:56
<gsnedders>
Darxus: "To obtain other glyphs, authors should use the 'content' property of the ::marker pseudo-element." — CSS3 Lists
17:56
<jacobolus>
if you do li:before won't that change the alignment
17:56
<Darxus>
jacobolus: I can, but I don't consider the inability... to do the above acceptable.
17:56
<Darxus>
jacobolus: Haven't tried it yet. My guess is the "before" part isn't necessary.
17:56
<jacobolus>
gsnedders: do browsers implement that?
17:56
<gsnedders>
jacobolus: No.
17:56
<jacobolus>
:)
17:57
<gsnedders>
jacobolus: But the fact that CSS3 says something about it means there's little point in writing to www-style :)
17:57
<jacobolus>
heh
17:57
<Darxus>
It's actually in CSS3.
17:57
<jacobolus>
IOW go complain in #webkit, on irc.mozilla.org, etc...
17:58
<jacobolus>
not that they'll have any sympathy
18:01
gsnedders
comes across Dashiva in BTS
18:04
<Philip`>
jacobolus: You can get a seemingly reasonably not-too-inaccurate list by doing something like
18:04
<Philip`>
gzip -cd fonts-in-inline-css-raw.txt.gz|sort -u|cut -f2|sort|perl -lne's/.*?://;print $1 while /('\''[^'\'']+'\''|"[^"]+"|[^\s,]+)/g'|sort|uniq -c|sort -n
18:05
<Darxus>
So that content trick seems to be not what I want. It's not changing the bullet, and so it's not doing the alignment I care about.
18:05
<Philip`>
and then ignoring the ones like "11px" which obviously aren't fonts
18:05
<Darxus>
Can't imagine how CSS has gone so long without allowing you to specify an arbitrary character as the bullet style.
18:05
<Philip`>
Might need to tweak the results so they're more meaningful e.g. counting number of pages each value appears on
18:05
<gsnedders>
Darxus: Images.
18:05
<Darxus>
gsnedders: Not acceptable.
18:06
<jacobolus>
Philip`: I was writing a python script to spit out all the font stacks :)
18:06
<Philip`>
Darxus: "<p>+ Line one.<br>+ Line two.</p>"
18:06
<Darxus>
I'll do a table. I think it actually sort of qualifies as tabular data.
18:06
<gsnedders>
Darxus: Well, obviously, seeming is has gone for so long it is acceptable
18:06
<Philip`>
jacobolus: I prefer bash+perl :-)
18:06
<Darxus>
Philip`: I want to alternate between + and -, the characters are different widths, so what I'm looking for is proper alignment.
18:07
<Darxus>
(Positive and negative attributes of the thing in the list heading.)
18:07
<jacobolus>
Philip`: I dunno whether you've done much python ever, but this is fun stuff: http://www.dabeaz.com/generators
18:07
<Philip`>
Darxus: "<p><span style=position:absolute>+</span>&nbsp; Line one.<br><span style=position:absolute>-</span>&nbsp; Line two.</p>"
18:07
<gsnedders>
jacobolus: But Python is slow!
18:08
<Darxus>
Nice, it looks like since yesterday whatwg overthrew w3 as the first google hit for html5.
18:08
<gsnedders>
We're back at number one!
18:20
<gsnedders>
Are scripts running upon being added to the DOM?
18:38
<gsnedders>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/188 should run per HTML 5, but doesn't in IE, Fx, Chromium, and only does in Opera
18:46
<Dashiva>
gsnedders: Snooping in canvas bugs, are you?
18:46
<gsnedders>
Dashiva: no
18:46
gsnedders
needs a break having been working for almost eight hours
18:46
<gsnedders>
Time to go home, I think
19:02
<annevk>
http://www.smashingmagazine.com/2009/07/29/misunderstanding-markup-xhtml-2-comic-strip/ is nice
19:03
<annevk>
except of course that XHTML as text/html is fiction :p
19:19
<tantek>
annevk - XHTML as text/html is not fiction - validates just fine with the W3C validator :)
19:20
<annevk>
that validator is also a piece of fiction :p
19:21
<annevk>
having said that, I don't really care that much what people do with their markup
19:22
<tantek>
annekv - you have a curious usage of the word "fiction" ;) http://validator.w3.org
19:25
<Hixie>
XHTML as text/html isn't fiction, it happens all the time
19:25
<Hixie>
the rules for how to process XHTML go out of the window when you use text/html though
19:25
<Hixie>
and with XHTML5, you can't have XHTML5 as text/html
19:31
<Hixie>
this Installed Apps thread had better be good
19:32
<weinig>
Hixie: :\
19:41
<annevk>
tantek, I'll give you that :)
19:57
<Hixie>
gsnedders_: why is it desireable for the parser to go out of its way to avoid multiple <body>s?
19:58
<Hixie>
gsnedders_: i'm not going to change the spec on that, at least not unless a good reason to do so is presented.
19:59
<Darxus>
What is the correct way to display a triple line break between paragraphs, to show greater separation?
19:59
<Darxus>
Er, correct markup.
20:00
<annevk>
<style> p { margin:2em 0 } </style>
20:00
<Hixie>
Darxus: <p>...</p><hr><p>...</p>
20:00
<Darxus>
Hixie: I like that one better, thanks.
20:00
<Hixie>
HTML5 then styles <hr> as hr { border: none; margin: 2em; } or something
20:02
<Darxus>
It took me a long time to give in to p's with end tags (used br's instead), but now I'm fond of them.
20:04
<Darxus>
You guys may enjoy reading up on Lojban, a synthetic human language designed to reduce language related limits on thought. No ambiguity.
20:05
<Darxus>
(And it's entirely HTML5's fault I ended up finding it - wondering how best to apply the HTML refinement process to human language.)
20:12
<Dashiva>
Darxus: There's always ambiguity, you just move it one step up in the hierarchy
20:17
<tfh>
ds++
20:33
<Darxus>
Dashiva: Where is there ambiguity in Lojban?
20:45
<Darxus>
CSS3 for lists is awfully extensive for not being able to specify a freaking character to use as the bullet: http://www.w3.org/TR/css3-lists/
20:46
<tantek>
Darxus, you may be looking for generated content.
20:46
<Darxus>
tantek: Somebody pointed me at that earlier, the problem is that it doesn't handle the alignment as a bullet.
20:47
<Darxus>
Oh, hah, I didn't realize that CSS3 (at least for lists) is also Hixies fault.
20:47
<Darxus>
Hixie: Fix it.
20:47
<Hixie>
i took a break from css to work on html5
20:47
<Darxus>
Ah.
20:47
<tantek>
I think I took the same break to work on microformats.
20:47
<Darxus>
Hixie: I would like to be able to specify any character to use as a bullet in a list.
20:48
<Hixie>
::marker { content: '' }
20:48
<Hixie>
iirc
20:48
<Darxus>
Particulary + / -, to list positive and negative aspects of something.
20:48
<tantek>
Darxus, I believe you may need to use generated content, and float:left, and text-align:right
20:48
<tantek>
oh and perhaps some negative margin-left
20:48
<tantek>
but you may find better luck to such questions in #css
20:48
<Darxus>
tantek: Tables work easy :P
20:49
<Darxus>
tantek: Talked to #css about it first.
20:50
<tantek>
Darxus, Hixie is right - see ::marker http://www.w3.org/TR/css3-lists/#markers
20:55
<Darxus>
tantek: Working on it, thanks. Any idea if any browsers have implimented it?
21:01
<Darxus>
Yeah I copied the example in the spec and it doesn't work in chrome or firefox 3.
21:01
<Darxus>
Hixie: But thanks for including it.
21:01
<tantek>
you may want to check their open source repositories for evidence of ::marker support
21:02
<tantek>
perhaps ask in the #webkit channel
21:03
<tantek>
and in #firefox
21:20
annevk2
finds http://www.pemberton.nl/vandf/2009/07/xhtml2-not-dead.html
21:24
<Hixie>
i wouldn't expect anyone to support the lists stuff yet
21:27
<annevk2>
iirc nobody went further than a bunch of the new keywords
22:38
annevk2
wonders if Thomas meant getting the name wrong with bad quoting or the top posting :p
22:39
Philip`
wonders who Philip is
22:40
<Philip`>
Maybe some weird mixup between Patrick and PHP?
23:09
<tantek>
in lieu of an email writeup in lieu of a wiki writeup (probably to follow at some point) :
23:09
<tantek>
While the HTML 4.01 definition of CITE
23:09
<tantek>
http://www.w3.org/TR/html401/struct/text.html#edef-CITE
23:09
<tantek>
"Contains a citation or a reference to other sources"
23:09
<tantek>
may be too vague,
23:09
<tantek>
the current HTML5 draft definition:
23:09
<tantek>
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-cite-element
23:09
<tantek>
"The cite element represents the title of a work..."
23:09
<tantek>
"A person's name is not the title of a work ..."
23:09
<tantek>
is a bit too narrow.
23:10
<tantek>
The cite element is for *any* kind of source, whether that source is:
23:10
<tantek>
* the title of a printed work, or
23:10
<tantek>
* a URL to an online work (should be represented by a nested hyperlink),
23:10
<tantek>
* or even the name of a person who said something, perhaps outloud in person or in an online chat such as IRC.
23:10
<Hixie>
why people?
23:10
<tantek>
Note that I am not advocating allowing marking up the name of an author of a work with cite, but rather, when the source/work is simply speech from an author that is not otherwise part of a work, then it is appropriate to markup the author (and their name or online nickname) as a cite.
23:10
<Hixie>
using <cite> for names is silly
23:10
<Hixie>
it's typographically wrong
23:10
<Hixie>
it's applying semantics where none are needed
23:10
<tantek>
Hixie, do you have a reference for why/how it is *typographically* wrong?
23:11
<Hixie>
sure, hold on
23:11
<tantek>
The precise semantic is that the *person* themsevles is the "other source".
23:11
<tantek>
when quoting from otherwise untitled/ungrouped speech from that person
23:12
<tantek>
thus the person themselves is the "other source" (per HTML 4.01 definition)
23:12
<tantek>
hence the usage of cite to refer to a speaker in such examples is semantically correct
23:13
<tantek>
(oops sorry about the nearly dup text there)
23:15
<tantek>
and also note that I am not advocating for general use of <cite> for names.
23:18
<tantek>
but rather for a very specific use for a person's name (or nickname if appropriate, e.g. for quoting from IRC) saying something which is quoted.
23:18
<Hixie>
my reference for the typography of names is going to be the chicacgo manual of style. I can't find anything in there that justifies using the same element for a title of a work and a name of a person, ever.
23:19
<Hixie>
<cite> is not for citations at all in html5
23:19
<Hixie>
it's just for titles of works
23:19
<Hixie>
because that's more useful in practice as far as i can tell
23:43
annevk2
thought the answer to http://twitter.com/johnfoliot/statuses/2918355573 has been long known
23:43
annevk2
wonders what this new wave of fake-ignorance is about
23:44
<tantek>
Hixie, in practice <cite> is also useful for names of speakers as noted above. E.g. http://rbach.priv.at/Microformats/IRC/2009-05-01
23:45
<Hixie>
tantek: how is it useful there?
23:45
<Hixie>
tantek: just use <dt> and <dialog> for a chat log.
23:45
<tantek>
the same as knowing what the "source" is for any quottation
23:45
<Hixie>
knowing what the "source" is for any quotation is not useful, as far as i can tell
23:45
<Hixie>
sounds useful
23:45
<Hixie>
but is not actually useful
23:46
<tantek>
it is useful, in that it provides a mechanism by which it may be possible to determine the validity of the quote
23:46
<tantek>
often by looking up the source
23:46
<Hixie>
you don't need an element for that
23:46
<tantek>
the same usefulness for citing any source
23:46
<Hixie>
what's the use for the element that can't be done without any element?
23:46
<tantek>
what is the harm in permitting an existing semantic usage to continue?
23:47
<Hixie>
that's _exactly_ what the spec is doing
23:47
<tantek>
I believe there is more weight on the side of keeping an existing practical usage, than dropping it. It doesn't appear to be doing any harm.
23:47
<Hixie>
the existing semantic usage is people use it for titles
23:47
<Hixie>
not citations
23:47
<tantek>
No the current draft spec is keeping one usage and dropping another.
23:49
<tantek>
people are using <cite> to refer to "other sources" per HTML 4.01. *one* of those other sources is the title of a work, another is a URL to a work, yet another is the name of a speaker of a quote. all of which are sources.
23:50
<tantek>
I understand the utility in refining the definition as given in HTML 4.01. However it seems to do more harm than good to ignore one of those existing uses, and disallow another, rather than explicitly allow all three existing uses.
23:50
<Hixie>
the vast majority of people who are using <cite> for any purpose other than "italics" are using <cite> to mean "title of work", not "cited name"
23:51
<Hixie>
and there is no good use for using it to mark up cited names that needs an element
23:51
<Hixie>
using it for names has one harm, it encourages people to use incorrect typography for names
23:51
<Hixie>
just look at anne's blog
23:51
<tantek>
Is Anne using it incorrectly?
23:51
<Hixie>
he's using it as you suggest
23:52
<tantek>
Hixie, it's not clear that "no good use for it" argument makes any sense, as any use case for the "title of a work" can also be made for the name of a speaker
23:53
<Hixie>
the only use case for title of work is "makes it italics", which doesn't apply to "name of a speaker"
23:53
<tantek>
I disagree - another use of the title of a work, and name of a speaker, is to look up said title/name and provide more information
23:53
<tantek>
about the source
23:53
<Hixie>
you don't need an element to do that
23:54
<tantek>
you do - in order to indicate what is the title or name of the speaker, as opposed to nearby text
23:54
<Hixie>
So if I say "Tantek said that you needed that", you wouldn't know that "Tantek" was a name, because I didn't mark it up?
23:55
<Hixie>
either i'm dramatically misunderstanding you, or someone gave you semantic web drugs this morning
23:55
<tantek>
entity discovery/resolution is buggy/unreliable, even in just one language, nevermind internationally.
23:55
<annevk2>
I stopped using <cite> that way btw
23:55
<tantek>
with the exception of very well defined text grammar
23:55
<Hixie>
people have no trouble understanding what is a name and what isn't
23:55
<tantek>
Hixie - depends on the language
23:55
<Hixie>
no, it really doesn't
23:56
<tantek>
and what about names that are not title-cased?
23:56
<Hixie>
like when i say that tantek said something?
23:56
<tantek>
Hixie - right
23:56
<Hixie>
you have no problem seeing the name there either
23:56
<tantek>
assuming you have a NLP that processes the sentence at all
23:56
<Hixie>
if you really, really, truly and honestly really desperately need some sort o machine-readable way to know that something is a name... use hCard
23:56
<tantek>
is the name "that tantek" or "tantek"
23:58
<tantek>
it gets more complicated in languages such as German where all nouns are capitalized
23:58
<Hixie>
please show me one example of that confusion actually happening, where <cite> would actually have helped.
23:58
<tantek>
Hixie - agreed that hCard helps to markup the name of a person and recognize it as such, especially if it has several name components (given, family, suffix etc.)
23:59
<tantek>
what <cite> does above and beyond that, is to indicate that that person is a *source*
23:59
<tantek>
which can then be connected to a quotation q through its cite attribute
23:59
<Hixie>
in html5, <cite> doesn't indicate that the thing is a source
23:59
<Hixie>
ok come now, nobody ever uses cite=""
23:59
<annevk2>
the main problem with using <cite> for this is, as I learned after I used it for a while, is that it is typographically incorrect, at least in English, to italicize the name
23:59
<Hixie>
i've seriously considered dropping cite="" altogether