00:23
<Hixie>
"Browsers don't implement feature X correctly, so we should add feature Y."
00:23
<Hixie>
^ one of the most common forms of feedback I see in the standards world.
00:23
<Hixie>
why not just wish for feature X to be fixed?
00:24
<bga_>
heh
00:24
<Hixie>
why do people assume feature Y will be implemented correctly?
00:24
<AryehGregor>
Because people don't think about things that way.
00:24
<TabAtkins>
It's because a lot of us are used to hacking around lacks. If browsers don't implement Feature X correctly, we do Hack Y to get around it. It's thus natural to assume that Hack Y should be prettied up and standardized.
00:24
<TabAtkins>
Not correct, but natural.
00:24
<hober>
There are dozens of political analogies that could be made here.
00:25
<TabAtkins>
Well, yeah. Solving The Wrong Problem is endemic in human reasoning. ^_^
00:25
<othermaciej>
morning, folks
00:26
<TabAtkins>
...where are you that this is morning for you? Japan or Australia?
00:26
<othermaciej>
Hixie: sometimes there could be plausible reasons that browsers wouldn't fix feature X (e.g. it's a UA-specific compat issue), but you are right, most of the time it is not well thought through
00:26
<AryehGregor>
Yeah, what? You're Pacific time or thereabouts, aren't you?
00:26
<TabAtkins>
Yeah, Maciej lives in the Bay Area.
00:26
AryehGregor
inferred that from CTCP TIME
01:08
<TabAtkins>
AryehGregor: In the end, I'm going to agree with you re: CSS3 Lists, and just special-case Hebrew. I can't decide how exactly to address the problem, so I'll see if I can solve it later.
01:10
<Hixie>
what's the hebrew issue?
01:10
<Hixie>
other than hebrew being insane
01:10
<TabAtkins>
It's not insane, it's just a normal additive language with a single exception (which can be represented efficiently in the additive-type syntax I have).
01:10
<TabAtkins>
The problem is the geresh, which doesn't fit with the basic algorithm I have for constructing additive lists.
01:11
<TabAtkins>
It'll require an exception to handle, and I'm not sure how I want to do that.
01:13
<TabAtkins>
So, instead of handling it, I'll just special-case the hebrew counter style and give an explicit algorithm.
01:13
<TabAtkins>
I'm already doing the same for ethiopian-numeric, and decimal.
01:13
<TabAtkins>
(Decimal doesn't cause any problem, but I need something that can't be overridden so it can act as the ultimate fallback.)
01:23
<Hixie>
hebrew wasn't simple when i was trying to spec it, but ok
01:23
<TabAtkins>
It's just like roman numerals, except with a geresh.
01:32
<Hixie>
roman numerals were pretty insane too, though from what i can tell i screwed up the algorithm quite a bit
01:33
<TabAtkins>
Nah, they're really easy to.
01:33
<TabAtkins>
Just a series of glyphs and weights in descending order of weight. Repeatedly grab the first glyph with a weight less than the current counter value, until the counter value hits 0.
01:34
<TabAtkins>
(That's the 'additive' type algorithm, used for roman numerals, tamil, and syriac.)
01:34
<TabAtkins>
(Oh, and georgian and a few others.)
01:35
<Hixie>
well so long as you don't make the mistakes i had in the original algorithm :-)
01:36
<TabAtkins>
Heh, I did it from scratch, so I shouldn't.
01:36
<TabAtkins>
I think Tamil's algorithm is wrong, though. I'll research it more next month.
01:36
<Hixie>
iirc one of the mistakes i made was using the Unicode roman numerals... i don't recall why that was bad though
01:36
<TabAtkins>
Yeah, those are deprecated.
01:37
<TabAtkins>
Unicode recommends not using them, and instead just using the ascii letters.
01:37
<Hixie>
what you describe doesn't seem to get you IV, V, VI... I assume the actual algorithm is more complex than you just described :-)
01:37
<Hixie>
but anyway
01:37
<TabAtkins>
additive-glyphs: "M" 1000, "CM" 900, "D" 500, "CD" 400, "C" 100, "XC" 90, "L" 50, "XL" 40, "X" 10, "IX" 9, "V" 5, "IV" 4, "I" 1;
01:38
<Hixie>
ah, multiple glyphs, ok
01:38
<TabAtkins>
Yeah, glyphs are strings or <image>s.
01:38
<TabAtkins>
I'm somewhat misusing the term.
01:48
<oojacoboo>
does gecko have @page implemented for print?
01:48
<jcranmer>
no
01:48
<oojacoboo>
wtf...
01:48
<oojacoboo>
it's been in the spec since the internet was invented
01:48
<TabAtkins>
I think fantasai wants to work on Gecko's paged media support next year.
01:48
<jcranmer>
gecko + printing = fail
01:49
<oojacoboo>
css media print is hard enough without having to deal with these serious UA issues
01:52
<othermaciej>
AryehGregor: I'm in Pacific time, yes, at least physically
02:26
<Hixie>
we really should set up a wiki page that tracks all the specs that apply to browsers
02:26
<Hixie>
(and that lists where pending feedback can be found and sent, etc)
05:46
<Hixie>
http://wiki.whatwg.org/wiki/Specifications_that_apply_to_Web_browsers
06:00
<abarth>
that could be a very large wiki page
06:03
<Hixie>
i'm sure we won't run out of electrons :-)
06:11
<abarth>
now much effort do you think it would be to spec the parsing / generation rules for HTTP?
06:12
<abarth>
s/now/how/
06:18
<abarth>
http://www.w3.org/Graphics/JPEG/ is a pretty lame spec of JPEG
06:19
<abarth>
which SVG spec do you want to link to?
06:19
<abarth>
http://www.w3.org/TR/SVG/ ?
06:25
<abarth>
ok, i doubled the size of your list off the top of my head
07:43
<Hixie>
abarth: figuring out the parsing rules of http would be a bitch because of the difficulty of testing it
07:43
<Hixie>
abarth: beyond that it'd be pretty easy though, i guess
07:43
<Hixie>
abarth: thanks for the contributions to the wiki page :-)
07:44
<abarth>
i guess you'd try to figure out the parsing using XMLHttpRequest
07:44
<abarth>
but, yeah, i can see that being tricky
08:48
<Philip`>
abarth|zZz: Is http://stuff.gsnedders.com/http-parsing.txt relevant?
08:48
<abarth|zZz>
Philip`: haven't seen that before
08:49
<abarth|zZz>
will look in detail later when not zZz :)
09:54
<gsnedders>
abarth|zZz: It really needs to be mostly rewritten, tbh
11:17
<annevk>
Hixie, I made http://wiki.whatwg.org/wiki/Specs at some point...
11:17
<annevk>
abarth|zZz, ^^
11:25
<_bga>
oh
11:26
<_bga>
i want send binary data *without* uri/utf8 encoding >_<
11:30
<annevk>
put it in the entity body?
11:30
<_bga>
from client
11:31
<_bga>
xhr encodes to utf8
11:31
<_bga>
except ff's sendAsBinary
11:32
<_bga>
:(
11:33
<_bga>
i tried <form action="/dump.app.js" charset="CP866" method="POST" enctype="multipart/form-data">, but all browsers encodes data to utf8 too
11:36
<_bga>
hm
11:44
<annevk>
you need to use accept-charset
12:17
<eighty4>
gsnedders: *ping*?
12:43
<Ms2ger>
Tab, why do you need display: marker? Wouldn't ::marker { content: pending(marker); } .marker { move-to: marker; } work?
18:50
<karlcow>
http://www.ietf.org/id/draft-ietf-websec-origin-00.txt
19:06
<abarth>
karlcow: yeah, its basically the same as its been for a while now, just moving forward in the IETF process
19:13
<Ms2ger>
[TODO: Security considerations.]
19:17
<Evet>
how to translate GTK to HTML5?
19:17
<abarth>
Ms2ger: yeah :)
19:48
<mven>
xen
20:08
<AryehGregor>
Hixie, the reason Hebrew list numbering seemed crazy to you is because you were being fed a nonstandard extended version that someone made up to handle arbitrarily large numbers, instead of the version everyone uses that only works up to about 1,000,000.
20:09
<AryehGregor>
So it had Hebrew words stuck in for strings of zeros.
20:09
<AryehGregor>
Although the version you were given wasn't too hard to understand if you knew Hebrew, since it mostly just spelled out the Hebrew words for numbers where they didn't fit nicely into the standard system.
20:10
<AryehGregor>
Sort of like if you'd write 1,000,000,001 as "1 thousand thousand thousand 1" if you had no symbol for 0 and no word for million/billion/etc.
20:11
<AryehGregor>
Anyway, I eventually got that axed. It was what got me into web standards development.
20:12
<AryehGregor>
Wait, so where's the new CSS lists spec?
20:13
<Ms2ger>
In Tab's head?
20:20
<espadrine>
Evet: http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ but DON'T DO IT!
20:21
<Evet>
espadrine: why not?
20:22
<espadrine>
Your app will probably be better off written in html5.
20:23
<espadrine>
This way you'll actually choose the stuff you really mean to do.
20:25
<Evet>
espadrine: indeed. but i want to port desktop applications to web
20:26
<espadrine>
Then it will only work in a minority of browsers for sure.
20:27
<Evet>
hmm
20:28
<espadrine>
The gtk3-vs-html5 stuff is implemented in canvas, which is a NEWT not available in ie6, 7, 8.
20:28
<Evet>
oh, even in 8
20:28
<espadrine>
Yes.
20:36
<karlcow>
Evet: do you mean porting desktop app to the browsers? because it is not exactly the same thing as the Web.
20:37
<Evet>
karlcow: yes
21:39
<Evet>
so, it looks writing new apps easier than porting dekstop apps to the browser.
23:11
<AryehGregor>
So how do I get colored diffs in hg that also allow scrolling with less, the way git does by default? Piping to less kills the color.
23:13
<Philip`>
[pager]
23:13
<Philip`>
pager = LESS='FRX' less
23:13
<Philip`>
[extensions]
23:13
<Philip`>
pager =
23:14
<Philip`>
Something like that, I think
23:14
<Philip`>
then just do "hg diff" and it'll page
23:15
<Philip`>
(plus use the color extension)
23:16
<AryehGregor>
Yay, more built-in extensions.
23:18
<AryehGregor>
But it works.
23:18
<AryehGregor>
Thanks.
23:50
<Hixie>
AryehGregor: ah!
23:50
<Hixie>
AryehGregor: good to know