01:05
<isherman>
Is there a handy way to print a stack trace when debugging WebKit code (outside of a debugger)?
01:05
<isherman>
oops, wrong channel...
05:52
<hsivonen>
I'm bad at using Microsoft APIs. I make the same mistake every time with attachEvent: I forget to prepend "on" to the event names
05:55
<annevk>
pretty pleased with Travis Leithead as editor for DOM Level 3 Events
05:56
<annevk>
not sure if it's because he addresses my comments mostly the way I want or just the pragmatic way (via testing and by tracking all changes publicly) he does so
05:56
<annevk>
hopefully the latter
06:23
<zcorpan>
why was this link not linkified correctly? http://krijnhoetmer.nl/irc-logs/whatwg/20120419#l-604
06:24
<annevk>
perhaps because the space after the link
06:24
<annevk>
just a guess
06:25
<zcorpan>
space after usually *helps* :-)
06:27
<annevk>
(e.g. "retarded waves" in http://en.wikipedia.org/wiki/Wheeler–Feynman_absorber_theory)
06:28
<annevk>
well that was not it
06:28
<annevk>
krijn: krijnh: URL regexp to fix ^^ fun times!
06:38
<zcorpan>
Ms2ger: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1481 seems opera doesn't have it
06:46
<zcorpan>
although opera doesn't seem to use 13px as base size there
06:47
<annevk>
replied to ietf-charsets
06:47
<annevk>
what's next...
07:01
<zcorpan>
"Our implementation of encodings WILL NOT change. Ever." - isn't that what microsoft said about the html parser too back in the day?
07:02
<annevk>
I was thinking of writing a blog post titled "same code points"
07:07
<annevk>
done http://annevankesteren.nl/2012/04/same-code-points
07:10
<annevk>
foolip: kennyluck: so it sounds like we want to combine big5-2003 and hkscs?
07:14
<kennyluck>
annevk, yeah, to achieve the maximum pages that are correctly decoded, hkscs still has a bunch of allowance that can be tweaked (they currently map to U+FFFD), although whether tweaking a legacy encoding at this point is a good idea or not is beyond my knowledge.
07:15
<annevk>
depends on the data
07:16
<annevk>
jgraham: in http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#indexes is "(as decimal number)" wrong?
07:16
<annevk>
jgraham: should it be "as a decimal number"?
07:58
<zcorpan>
i didn't know U+0040 was called "COMMERCIAL AT"
08:06
<annevk>
why does IE not support URLs such as data:text/html;charset=ibm864,%A7
08:06
<annevk>
oh well
08:07
<zcorpan>
TabAtkins: U+005C REVERSE SOLIDUS (\) in 3.4.4. Double-quote-string state doesn't seem to support char escapes like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1483
08:11
<zcorpan>
TabAtkins: "Otherwise, create a hash token with its value set to the returned character." (hash state), what's the returned character?
08:12
<zcorpan>
(i think both should use "consume an escaped character")
08:18
<AryehGregor>
This is so, so, so, so true: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
08:19
<AryehGregor>
And for anyone who says "But Wikipedia is written in PHP!" -- I can assure you as a former MediaWiki developer that most MediaWiki developers hate PHP and wish it were written in something else.
08:20
<annevk>
MikeSmith: http://dvcs.w3.org/hg/encoding/rev/94f075e5eabb yields 500
08:23
<hsivonen>
so does anyone know what I need to do to see document.readyState == 'loading' in IE?
08:24
<hsivonen>
I didn't expect the spec and the IE behavior to be *this* far apart for a feature introduced by IE
08:28
<[tm]>
annevk: away from my PC. off to meet my daughter for dinner. will check it when i get back
08:29
<annevk>
http://webkitmemes.tumblr.com/post/18511335915/seems-easier-to-just-e-mail-anders-and-sam heh
08:29
<annevk>
[tm]: no rush man
08:30
<annevk>
I remember there was a similar thing in 2004 or so where IBM had this really specific Gecko listing
08:32
<hsivonen>
this: http://ln.hixie.ch/?start=1052961695&count=1
08:32
<hsivonen>
2003 even
08:32
<annevk>
thank you!
08:33
<annevk>
I thought it was bz that had posted it
08:37
<hsivonen>
OK. This shows "loading" but no "interactive" in IE9: http://hsivonen.iki.fi/test/moz/readystate/document-open.html
08:38
<hsivonen>
no two browser engines do the same thing on that demo
08:38
<hsivonen>
Gecko 14 and Chrome 20 do the same thing if you ignore differences in support for FrameDOMContentLoaded
08:49
Ms2ger
grumbles at Opera's projection stuff
08:49
<hsivonen>
ok. I added one more log() call after calling document.close() do show that Gecko and WebKit are radically different, too
08:50
<hsivonen>
somehow, the Web works with this level of blatant differences in document loading
08:50
<annevk>
Ms2ger: find me an easier way to write a presentation and I'll use it
08:51
<Ms2ger>
annevk, oh, I like it
08:51
<Ms2ger>
Only pgdn moves slightly too far down, somehow
08:52
<annevk>
oh
08:52
<annevk>
sounds like a bug
08:54
<foolip>
annevk, kennyluck, I'm not sure about that, if Big5-2003 doesn't conflict at all with HKSCS that might work, but only cherry-picking from 2003 seems a bit weird.
08:54
<annevk>
big5 -> big5-2003 -> big5-hkscs
08:54
<foolip>
Also, the 2003 mappings don't actually seem to work that well for all the pages I listed, but that email is still in my outbox
08:54
<annevk>
ah
08:55
<foolip>
annevk, are you saying that 2003 is a strict subset of hkscs?
08:55
<kennyluck>
big5-hkscs is certainly not a superset of big5-2003 last I check.
08:55
<foolip>
right, I didn't think so
08:55
<annevk>
foolip: no I'm saying that's how we could layer things
08:56
<annevk>
but if big5-2003 is not actually that great that would not make sense of course
08:57
<kennyluck>
foolip, yeah, cherry picking doesn't always work.
08:57
kennyluck
is waiting for that mail.
08:57
<foolip>
kennyluck, tonight, it's on my computer at home :)
08:58
<annevk>
so what should happen for the encoder?
08:58
<foolip>
if an authoritative (non-PUA) mapping for Big5-2003 exists it would be easier to figure out, it's hard to have confidence in a mapping deduced from relatively few sitse
08:58
<foolip>
annevk, depends on the decoder(s), right?
08:58
<foolip>
annevk, btw, your exchange with Shayne was a good read on the bus :)
08:58
<kennyluck>
No, I think we should only do CP950 encoding.
08:58
<annevk>
foolip: heh
08:59
<kennyluck>
or a non-PUA subset, I don't know.
09:00
<foolip>
does CP950 include HKSCS?
09:00
<annevk>
no
09:00
<annevk>
http://en.wikipedia.org/wiki/Code_page_950
09:01
<foolip>
not encoding Cantonese properly when labeled as Big5 seems like a bad idea
09:01
<foolip>
the question, to me, is if there exists another encoding than HKSCS that would work better for Taiwan or not
09:02
<foolip>
Firefox's UAO doesn't seem to be it, not without modification
09:04
<foolip>
Figuring out how that ~UAO content ended up on the Web (using which OS and which fonts) would probably give some clues.
09:05
<kennyluck>
I don't think it's a bad idea to output as much numeric character references either, though I am not knowledgable about the security implication of a non-bidirectional approach.
09:06
<hsivonen>
Stuff I just learned: calling document.write will make IE9 start layout sooner
09:08
<kennyluck>
foolip, For UAO, you just install the UAO package on Windows and you are starting to produce UAO content. I am more curious about how non-UAO big5-2003 ended up on the Web...
09:08
<foolip>
kennyluck, does that UAO package include a font as well?
09:08
<foolip>
perhaps looking at these pages using that installed will reveal something...
09:09
<Ms2ger>
Hmm
09:10
<Ms2ger>
Opera still doesn't support clamping for ImageData.data?
09:11
<hsivonen>
TimBL is not Father of the Internet: https://twitter.com/#!/EU_Justice/status/193264746798129152
09:11
<hsivonen>
s/not/now/
09:12
<annevk>
is that a promotion?
09:12
<Ms2ger>
He is now Al Gore
09:14
<hsivonen>
I'm too lazy to reorganize my code to work in IE6
09:14
<hsivonen>
now that it works in IE8
09:14
<hsivonen>
"works" meaning that the logging code runs successfully in my readyState demos
09:15
<hsivonen>
it's rather surprising what doesn't work in IE6
09:15
<hsivonen>
either closures or .contentDocument at particular moments
09:16
<zcorpan>
foolip, annevk: http://simon.html5.org/dump/encoding-labels/TODO
09:16
<hsivonen>
so I give up on establishing a baseline that'd show both "loading" and "interactive" in any version of IE
09:16
<hsivonen>
I guess I'll just move on to more complex cases now and conclude that IE is buggy even at baseline
09:17
<foolip>
zcorpan, I can generate a list of URLs from the top million sites if that would help
09:17
<annevk>
zcorpan: I think today I can start writing the detection algorithm, but maybe I'll update WebVTT first
09:17
<hsivonen>
I think it's fair to describe an IE-introduced feature as buggy in IE when it behaves non-sensically and contrary to MSDN docs
09:17
<annevk>
I'm also sleep deprived, so maybe it'll spread out over the weekend :)
09:18
<hsivonen>
Stuff to test:
09:18
<hsivonen>
1) Normal external script
09:18
<hsivonen>
2) slow async script
09:18
<hsivonen>
3) defer script
09:18
<hsivonen>
4) slow defer script
09:18
<hsivonen>
5) slow image
09:18
<annevk>
zcorpan: also, 1) thanks for the help and 2) I fixed some label typos in the draft and updated the Opera mismatch data
09:18
<hsivonen>
6) window.stop()
09:18
<hsivonen>
7) XSLT that works
09:19
<hsivonen>
8) XSLT that fails
09:19
<hsivonen>
9) XML that works
09:19
<hsivonen>
10) XML that fails
09:19
<hsivonen>
11) XHR
09:19
<hsivonen>
12) document.open() in mid-stream
09:19
<hsivonen>
13) window.location in mid-stream
09:20
<hsivonen>
14) window.location.reload() in mid-stream
09:20
<hsivonen>
What else?
09:21
<hsivonen>
15) Detaching the host iframe from doc in mid-stream
09:21
<zcorpan>
foolip: i guess that could be useful
09:21
<annevk>
CSS loading?
09:22
<foolip>
zcorpan, don't guess, it would take 12 days to generate
09:22
<zcorpan>
foolip: it'd take days to run the research too, but i don't have immediate plans to do it :-)
09:23
<foolip>
zcorpan, ok, let me know if you need Bing results and don't wanna set it up yourself later :)
09:23
<zcorpan>
so, wait with generating it until there's code to run the research
09:23
<zcorpan>
k
09:25
<annevk>
what is the stability of WebVTT these days foolip?
09:25
<foolip>
annevk, still undergoing tweaking, but I don't expect the basic syntax will break
09:25
<foolip>
possibly line endings will change, but I'm not sure
09:25
<annevk>
line endings really?
09:26
<zcorpan>
<br> has been proposed
09:26
<annevk>
is that why nobody is bugging me about the parser/validator or does nobody care?
09:26
<hsivonen>
WebVTT: reinventing HTML one tag at a time. :-)
09:26
<annevk>
because if it's still in flux maybe I better work some more on encodings
09:27
<foolip>
annevk, I don't think the spec has changed much since you wrote it
09:28
<annevk>
http://dev.w3.org/html5/webvtt/#parse-the-webvtt-settings has changed
09:28
<annevk>
now there's "vertical" and such
09:29
<annevk>
I guess I'll just add that in, should not be hard
09:31
<hsivonen>
Chrome behaves more sensibly with an external script present: http://hsivonen.iki.fi/test/moz/readystate/document-open-external-script.html
09:33
<hsivonen>
IE9 doesn't behave sensibly
09:33
<Ms2ger>
News at 10
09:33
<zcorpan>
annevk: did you fix --> handling?
09:34
<hsivonen>
\o/ The external script makes IE10 almost sensible
09:34
<hsivonen>
but not quite
09:34
<hsivonen>
there's a readystate change from loading to loading
09:35
<annevk>
zcorpan: probably not?
09:37
<zcorpan>
annevk: the spec changed at some point to always make --> start a new cue
09:39
<annevk>
oh yeah I think I fixed that
09:41
<zcorpan>
ok
10:15
<annevk>
fixed http://quuz.org/webvtt/
10:16
<annevk>
https://bitbucket.org/annevk/webvtt/changeset/f8c4f81a15a4 is the changeset
10:19
<zcorpan>
oh yeah, iirc there's a bug on allowing a space after the colon in the settings
10:20
<annevk>
enabling that would suck
10:20
<annevk>
but it's not big deal
10:20
<zcorpan>
not supporting it sucks for authors, imho :-)
10:21
<annevk>
changing the format all the time does too
10:22
<annevk>
although this would technically be a compatible change
10:45
<zcorpan>
hmm, maybe encoding-labels/TODO should not bother with adjusting the fallback encoding, since if recognizing more labels means more content works regardless of what the fallback encoding is, that seems like a win
10:46
<hsivonen>
now after lunch, I've made defer scripts on my list and I'm already finding shocking things
10:46
<zcorpan>
(for pages that declare their encoding using one of the funny labels and it happens to match the fallback encoding for the majority of people reading those pages)
10:46
<hsivonen>
this whole area may indeed be so full of uninteroperable bugs that we can fix stuff if we want to
10:47
<Velmont>
^^
10:47
<Ms2ger>
Woo!
10:47
<Velmont>
Many incompatible bugs => Goodie, we can fix it. :]
10:47
<zcorpan>
hsivonen: fix stuff if we want to? No! WE WILL NEVER CHANGE.
10:58
<hsivonen>
everyone likes having their browser locked while the XSLT engine computes n-queens: https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/entry/n_queens_xsl_xml14?lang=en
11:02
<annevk>
zcorpan: yeah I think we should add cpXXXX stuff
11:02
<annevk>
most of the ones Opera recognizes are ones that only one other impl does not
11:02
<annevk>
although the microsoft-XXXX are dubious
11:11
<hsivonen>
jgraham: window.stop really aborts the parser in Gecko and WebKit but not in Opera: http://hsivonen.iki.fi/test/moz/readystate/window-stop.html
11:12
<zcorpan>
ok somebody needs to patch Lynx to support <blink>
11:14
<hsivonen>
this is such a mess. window.stop() suppressed pageshow in WebKit but not in Gecko
11:14
<hsivonen>
in WebKit, the parser aborts synchronously
11:15
<hsivonen>
in Gecko, upon window.stop(), pageshow fires before DOMContentLoaded
11:16
<hsivonen>
whoa. msdn search searches StackOverflow these days
11:18
<smaug____>
hmm, what does the spec say about pageshow
11:19
<hsivonen>
smaug____: should fire after "load"
11:20
<smaug____>
but what if there is no load
11:20
<smaug____>
at least spec is wrong here
11:20
<smaug____>
no doubt, implementations too
11:20
<hsivonen>
pretty much everything is wrong here
11:23
<jgraham>
hsivonen: Interesting
11:24
<jgraham>
I am not at peak productivity at the moment due to installing a new OS to avoid dataloss due to impending HD failure
11:25
<jgraham>
So far I am not impressed with the amount of time it is taking me to set stuff up, or with the last two years of ubuntu development
11:25
<gsnedders>
jgraham: Mint > Ubuntu.
11:26
<jgraham>
gsnedders: iirc they were doing some evil thing with their browser configuration. Also I like distributions that I think will still have a substantial userbase in two years
11:27
<jgraham>
And, you know, I will probably eventually manage to make the launcher thing work in a non-retarded way
11:28
<jgraham>
And figure out how to change the keyboard bindings that I don't like
11:29
<gsnedders>
jgraham: I'd expect Mint to still have a significant userbase in two years, and to continue its current growth (mainly to the detriment of its upstream Ubuntu).
11:36
<hsivonen>
gsnedders: what's actually better about Mint?
11:36
<hsivonen>
can I buy support for Mint? is there an equivalent of askubuntu.com for Mint?
11:37
<hsivonen>
does Mint hibernate better?
11:37
<hsivonen>
does Mint actually do proper regression testing of drivers?
11:37
<gsnedders>
hsivonen: It seems less buggy, and the UI hasn't been bastardized.
11:38
<hsivonen>
gsnedders: how can it be less buggy if it's downstream from Ubuntu?
11:38
<gsnedders>
I doubt at a low-level it's any less buggy, though, given it's basically just a set of packages on top of Ubuntu.
11:38
<hsivonen>
is it Gnome2 or Gnome3?
11:38
<gsnedders>
hsivonen: A lot of the GNOME packages are n't the Ubuntu ones, for example
11:38
<hsivonen>
I actually prefer Unity over Gnome2
11:38
<hsivonen>
I haven't used Gnome3
11:38
<hsivonen>
so it's like Ubuntu with vanilla Gnome?
11:39
<gsnedders>
hsivonen: You have a choice of MATE (GNOME2 fork) or GNOME3, albeit with a fairly custom UI which actually is usable
11:39
<hsivonen>
ok
11:39
<gsnedders>
(I at least find vanilla GNOME3 really confuisng)
11:41
<gsnedders>
hsivonen: I guess some perception of buginess is down to the fact they will delay releases more than Ubuntu do for critical bugs.
11:43
<jgraham>
Right, I figured out how to open the launcher thing with a key so now I can hide it. Now only the top menu thing is annoying. Well not only that but it's the thing I can see
11:44
<jgraham>
If anyone knows how I can bind a shortcut to "move window to other monitor" please let me know. I didn't see it in the prefs
11:46
<AlexNRoss>
I have a question in regards to WAI-ARIA as described on the WHATWG HTML5 spec.
11:47
<AlexNRoss>
It states that <ol> may have a role of "tablist", however the W3 Validator disagrees with this.
11:48
<AlexNRoss>
Can anyone determine if it is W3 Validator that is incorrect or if it is a mishap in the HTML5 spec?
11:51
<AlexNRoss>
Example: http://pastebin.com/n5Z3LJ8L
11:51
<[tm]>
al
11:51
<Velmont>
jgraham: I've moved my work machines over to Arch Linux. :-)
11:52
<Velmont>
(or, am moving right now. Hate copying files, so disk-bound)
11:52
<hsivonen>
gsnedders: what's the business model of Mint?
11:53
<[tm]>
AlexNRoss: validator not up to date with the spec. working on it
11:53
<AlexNRoss>
Alright.
11:54
<[tm]>
AlexNRoss: please file a bug
11:57
<gsnedders>
hsivonen: There isn't one. The development is all done by volunters, which is somewhat disconcerting.
12:08
<hsivonen>
posted about window.stop() substitute in IE on StackOverflow: http://stackoverflow.com/questions/10245972/aborting-the-parser-from-javascript-in-internet-explorer
12:12
<hsivonen>
gsnedders: well, volunteer development works for Debian
12:12
<hsivonen>
gsnedders: I'm just a bit suspicious about elaborate $0 stuff without an obvious monetization model out of fear of the model being "you are the product@
12:12
<hsivonen>
s/@/"/
12:14
<hsivonen>
w00t. StackOverflow question already has an answer!
12:15
<Ms2ger>
Woo, execCommand
12:19
<hsivonen>
Huh? "You can accept an answer in 3 minutes"
12:23
<hsivonen>
looks like the other engines don't support execCommand("Stop")
12:26
<zcorpan>
that's a thing?
12:28
<hsivonen>
still more stuff to test before drawing conclusions
12:32
zcorpan
wonders if anyone knows the answer to https://www.w3.org/Bugs/Public/show_bug.cgi?id=12998#c14
12:35
<zcorpan>
anyone have a good idea for a new #csspubquiz?
12:37
<hsivonen>
zcorpan: I sent email to people who should know
12:37
<zcorpan>
cheers
12:50
<hsivonen>
why doesn't document.open() blow away "Text before script" here: http://hsivonen.iki.fi/test/moz/readystate/open.html ?
12:54
<Ms2ger>
"If the document has an active parser that isn't a script-created parser, and the insertion point associated with that parser's input stream is not undefined (that is, it does point to somewhere in the input stream), then the method does nothing. Abort these steps and return the Document object on which the method was invoked."
13:02
<hsivonen>
Ms2ger: oh
13:02
<hsivonen>
Ms2ger: thanks
13:17
<zcorpan>
MikeSmith: https://bitbucket.org/validator/validator/changeset/5f1a14c441c8 i'd use bold.appendChild(elementToHighlight) instead of setting innerHTML
13:17
<annevk>
hmm zcorpan, http://code.google.com/p/html5lib/source/browse/python/html5lib/inputstream.py contains encoding detection in Python
13:18
<annevk>
not sure how easy it is to extract though
13:19
<jgraham>
annevk: Should be rather easy I think. But probably not that quick to run
13:20
<[tm]>
zcorpan: ok, will change it when I'm back to my rig
13:24
<annevk>
so is the spec intentionally buggy?
13:24
<annevk>
</x t="><meta charset=utf-8>
13:25
<annevk>
prescan finds <meta>
13:26
<hsivonen>
annevk: unclear what's intentional and what's not there
13:27
<annevk>
hsivonen: are there open bugs in this area?
13:28
<zcorpan>
<!----!><meta charset=utf-8> is not found
13:30
<hsivonen>
annevk: I don't recall any
13:31
<zcorpan>
annevk: "A sequence of bytes starting with a 0x3C byte (ASCII <), optionally a 0x2F byte (ASCII /), and finally a byte in the range 0x41-0x5A or 0x61-0x7A (an ASCII letter)" seems to properly skip attributes for your case
13:34
<annevk>
zcorpan: I did not realize that covered / as well, my bad
13:35
<annevk>
thanks
13:35
<zcorpan>
though supporting --!> might be slightly annoying because the dashes can't overlap with <!--, unlike with -->
13:35
<zcorpan>
but might still be worth doing
13:37
zcorpan
filed
13:38
<hsivonen>
still XSLT testing to do...
13:38
<hsivonen>
I've again forgotten what I knew about XSLT.
13:39
<jgraham>
I find it very easy to remember that I know nothing about xslt
13:40
<hsivonen>
oh and detaching the iframe
13:40
<jgraham>
And reattaching it?
13:40
<hsivonen>
I wasn't going to reattach
13:41
<jgraham>
It seems that reattching is interesting in at least some cases
13:41
<jgraham>
In that we have, in general, not related to readyState in particular, had bugs about detaching and reattching iframes
13:42
<AlexNRoss>
hsivonen: XSLT is a complete waste. Just use CSS.
13:43
<jgraham>
AlexNRoss: He is implementing the browser not writing websites
13:43
<AlexNRoss>
Ah.
13:43
<jgraham>
Although I think we would all be very happy if XSLT could be nuked from orbit
13:44
<AlexNRoss>
Ya. It is less compatible than CSS, not as functional as CSS, and it is very primitive. In addition to that, it is for XML only.
13:45
<zcorpan>
can't it be used with html with the dom api?
13:45
<AlexNRoss>
That and <blink> as well as anything older than HTML 4.01 should also be nuked.
13:46
<AlexNRoss>
zcorpan: You're using an API? You can do anything then at that point to stylize things.
13:46
<Philip`>
Please don't nuke <plaintext> yet :-(
13:47
<AlexNRoss>
That reminds me. Whoever made Joomla! and jQuery should be tortured to death very slowly and painfully.
13:47
<hsivonen>
AlexNRoss: that's not nice
13:47
<AlexNRoss>
Their products aren't very nice and influences society in a bad way.
13:47
<Philip`>
Less collateral damage than nuking, though
13:48
<AlexNRoss>
Like there is sites that use the jQuery API just to do a little bit of JavaScript. It has essentially taken away peoples' ability to do normal JavaScript.
13:49
<Ms2ger>
[Note: we do not condone torture]
13:49
<AlexNRoss>
And doing it the normal way uses less processing and resources as well as less bandwidth consumption and faster load time.
13:49
<zewt>
[Note: except when people really annoy us]
13:50
<Philip`>
AlexNRoss: I thought it was more that it had taken aware people's desire to do normal JavaScript, since it removes some of the basic pains of JS
13:50
<Ms2ger>
I'm all for jquery-hatin', myself
13:50
<Ms2ger>
But be nice to the people, please?
13:50
<AlexNRoss>
Hardly Philip.
13:50
zcorpan
finds out his latest quiz has a pretty low CORE- number
13:51
<AlexNRoss>
And Joomla! it is the next level of CMS retardation.
13:51
<Ms2ger>
zcorpan, block, I guess
13:51
<AlexNRoss>
CMS apps are for people who know nothing about programming to update their site, I get it. But Joomla! takes things to a whole new level of stupidity.
13:51
Philip`
doesn't trust anything with punctuation in its name
13:51
<annevk>
zcorpan: that's buggy in Opera?
13:52
<zcorpan>
annevk: you filed the bug :-P
13:52
Ms2ger
doesn't trust anybody with punctuation in their name
13:52
Ms2ger
waves at Philip`
13:52
zcorpan
doesn't trust anyone with numbers in their name
13:52
<Ms2ger>
Me neither
13:52
<Philip`>
Ms2ger: That's not punctuation, it's just a symbol to avoid naming conflicts
13:52
<Ms2ger>
I mean, have you ever met me?
13:52
<annevk>
zcorpan: you should have asked about display:list-item :p
13:52
<annevk>
zcorpan: what's the number? :)
13:53
<zcorpan>
CORE-1285
13:53
<Philip`>
If it was "'" then you could argue that it's punctuational depending on context, but "`" isn't even that
13:53
Ms2ger
whacks zcorpan with 915
13:54
<Ms2ger>
Philip`, I don't need arguments :)
13:54
<annevk>
zcorpan: heh, long time ago
13:54
<annevk>
zcorpan: guess the CSS 2.1 test suite does not cover that then
13:54
Ms2ger
sniggers
13:54
<annevk>
but it went to REC, mwahaha
13:55
<zcorpan>
Ms2ger: 915 is still not WONTFIXed?
13:55
<Ms2ger>
No
13:55
<annevk>
classic
13:56
<annevk>
heh
13:56
<annevk>
Gecko still has a bug for full HTML 4 support
13:56
<zcorpan>
heh, the last comment is funny since we now have an html5 parser :-)
13:56
<jgraham>
Oh I thought that the ` was to indicate the Philip` was derivative
13:56
<annevk>
"Bug 41368 - (robin's) Fails test cases in Robin's HTML 4.0 Conformance Test"
13:57
<AlexNRoss>
Unless Philip` is meant to be <html>Phili&pgrave;</html>
13:57
<Ms2ger>
With an "investigate more" from Hixie in the whiteboard, hah
13:58
<annevk>
https://bugzilla.mozilla.org/show_bug.cgi?id=1996 longdesc has a [Hixie-P4]
13:58
<annevk>
Bugzilla is a treasure trove
13:58
<zcorpan>
maybe we should drop support for <col align> in opera
13:59
<annevk>
you want our very own 915?
13:59
<zcorpan>
yeah!
13:59
<AlexNRoss>
IMO: longdesc is pointless.
14:00
<AlexNRoss>
You can describe the image if it isn't there with alt
14:00
<AlexNRoss>
Title is for a tooltip blurb.
14:00
<AlexNRoss>
Not to meantion, there is also an aria-describedby too.
14:01
<AlexNRoss>
Too many attributes for one thing.
14:01
<AlexNRoss>
It gets redundant, annoying, and cumbersome.
14:01
<AlexNRoss>
mention*
14:03
<Philip`>
Also, nobody uses it, and of those who use it, nobody uses it correctly
14:04
<Philip`>
Unsurprisingly, http://www.w3.org/html/wg/tracker/issues/30 is still an open issue
14:08
<AlexNRoss>
IMO: There should be a rule put down for browsers: Once something as been obsoleted by a RFC or by the latest HTML Spec, it should only be around for a maximum of 10 years afterwards. If sites haven't updated by that point, they're clearly not updated and shouldn't exist on the internet.
14:09
<jgraham>
Homework quiz: work out if the e above proposal represents a stable equilibrium for browser vendors
14:10
<Philip`>
AlexNRoss: There's no incentive for browsers to delete support for old features, since they've already implemented them and they'd prefer not to break pages
14:10
<Philip`>
There's plenty of modern sites that rely on ancient obsolete features, too
14:10
<AlexNRoss>
Philip, I realize that, but doing so also just feeds the ancient websites.
14:11
<Philip`>
Non-trivial risk plus zero reward does not provide a very compelling motivation :-)
14:11
<AlexNRoss>
Modern sites that use <plaintext>, <blink>, and <script language="javascript">?
14:12
<AlexNRoss>
Philip: There is a reward: It then forces websites to stay at least somewhat updated.
14:12
<jgraham>
That's just a thing
14:12
<AlexNRoss>
It would make for a much nicer web viewing experience.
14:12
<jgraham>
It's not a reward
14:12
<Philip`>
I think Opera recently (well, a few years ago) experienced bugs on some modern heavily JS-based site due to its parsing of <xmp>
14:12
<AlexNRoss>
Rather than seeing sites that use tables for layout and HTML 3.0, etc.
14:13
<AlexNRoss>
<xmp> isn't a HTML entity.
14:14
<Philip`>
Sure it is
14:14
<Philip`>
It's even listed in http://tools.ietf.org/html/rfc1866#section-5.5.2.1
14:18
<AlexNRoss>
Well they aren't in HTML5 spec anyhow.
14:18
<AlexNRoss>
And I can see why they were removed.
14:18
<AlexNRoss>
You have <ol> <ul> and <dl> for lists.
14:19
<AlexNRoss>
Why would you need <xmp> and <listing>?
14:20
<Philip`>
AlexNRoss: Search for "xmp" in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody
14:20
<AlexNRoss>
http://www.whatwg.org/specs/web-apps/current-work/multipage/
14:20
<AlexNRoss>
Search "xmp". 0/0 found
14:20
<Philip`>
That just means it's not part of the conforming language for documents to use
14:20
<Philip`>
which has always been the case, since it's been obsolete/deprecated/etc since forever
14:21
<Philip`>
Implementations are still required to parse it with special rules
14:22
<AlexNRoss>
Essentially, you're just trying to protect ancient sites or sites that are so horrible that nobody would ever go to them.
14:22
<AlexNRoss>
Example: http://www.lingscars.com/
14:24
<annevk>
AlexNRoss: it's important to preserve history
14:25
<AlexNRoss>
Then you should work for a meuseum. Hell, I bet that meuseum's website is more up to date than Ling's Cars.
14:26
<Ms2ger>
Well, no
14:26
<Ms2ger>
His qualities are much more appreciated here
14:27
<AlexNRoss>
The internet is vast and anything prior to 10 years from it's updates really shouldn't be around IMO.
14:27
<Philip`>
AlexNRoss: <xmp> broke Backbase in Opera
14:27
<Philip`>
which was an actively-developed site
14:27
<Ms2ger>
Well, unfortunately you're pretty much alone there
14:27
<Philip`>
(in 2007, it seems)
14:28
<Philip`>
so it's not just ancient or horrible sites
14:28
<Philip`>
It's just sites with crazy developers, which is pretty much the whole of the web :-)
14:29
<AlexNRoss>
Ms2ger: You can quote me on this: Before 2050 comes, things like <plaintext>, <blink>, <xmp> and <listing> will not be supported by browsers and will just be a memory to people.
14:29
<Ms2ger>
Sure
14:29
<Ms2ger>
I will
14:29
Philip`
is happy he remembered there was some site it broke, but had to check the bug database to find exactly which one :-(
14:29
<AlexNRoss>
And you'll see how wrong you are in 2050.
14:29
<Ms2ger>
And you will turn out to have been wrong :)
14:31
<Philip`>
I hope we're not still using HTML by then
14:31
<Philip`>
so all HTML that still exists will be legacy stuff
14:31
<Ms2ger>
XHTML2! :)
14:32
<Philip`>
and the sole purpose of an HTML browser will be to preserve access to legacy content that hasn't yet been ported to the new neural augmented reality data visualisation language
14:32
<jgraham>
What makes you think that language won't be built on top of html
14:33
<jgraham>
It will be <!doctype html><html><script>new Reality()</script>
14:36
<Philip`>
jgraham: The new 4D metaverse will doubtless be designed by Facebook, and they wouldn't want to let browser vendors act as gatekeepers
14:37
<Philip`>
Everyone wants full control over the platforms they're building on, and open standard multi-vendor HTML isn't a good fit for that
14:38
<AlexNRoss>
Philip: Not a chance, Google will be the first ones on board for any new technological advances in web development.
14:39
<Philip`>
Facebook will buy Google
14:39
<Philip`>
(You can quote me on that)
14:40
<Ms2ger>
Hah
14:40
<hsivonen>
http://my.opera.com/desktopteam/blog/2012/04/20/update-on-hardware-acceleration-in-opera-12 opt in. so that's what's been delaying Opera 12 on desktop
14:40
<Ms2ger>
Google is the first on board to push proprietary crap, that for sure
14:40
<jgraham>
Philip`: Pretty sure you are supposed to say things like that in the manner of roc i.e. "I predict 906a59544029a67d5fb6e92f1fd663a6"
14:41
<Ms2ger>
Poor roc
14:43
<Philip`>
jgraham: By 2050, surely people will be able to break MD5
14:43
<Philip`>
Better to be forward-thinking and predict something like e48dcff1e0a381cc99548d949f5dc4e3c042dbe01ebea140efbbac36aca541e453598dc5ea3467e71ad7119c0ce65b993c81884f97d23c618c7aa88ac6c6ef8f
14:45
<hsivonen>
"We want to bring the first true hardware accelerated browser to market."
14:45
<hsivonen>
nice way to spin Opera last into yet another Opera had it first. :-)
14:45
<Philip`>
As in the first true Scotsman?
14:45
<jgraham>
Speaking of Scotsmen, I hear gsnedders is no longer a teenager
14:46
<jgraham>
So, uh, I hope you are having a happy birthday. Because frankly I'm terrified
14:46
<Ms2ger>
Heh
14:46
<hsivonen>
gsnedders: happy birthday
14:46
<Ms2ger>
Congratulations and stuff
14:49
<annevk>
whoa gsnedders is twenty now?
14:50
<annevk>
congrats
14:57
<paul_irish>
\o/
15:09
<hober>
gsnedders: happy birthday!
15:11
<foolip>
gsnedders, 25% dead, congrats!
15:11
<foolip>
(according to http://en.wikipedia.org/wiki/List_of_countries_by_life_expectancy)
15:14
<Philip`>
foolip: That's misleading since the stats are for the whole UK, not for Scotland
15:15
<Philip`>
(e.g. http://www.bbc.co.uk/news/uk-scotland-12898723 says "people from the rest of the UK live around two years longer than the Scottish average")
15:16
<foolip>
gsnedders, >25% dead, congrats!
15:19
<jgraham>
In glasgow it can be even lower
15:19
<foolip>
Aren't we a merry bunch...
15:19
<jgraham>
http://www.bbc.co.uk/news/uk-scotland-glasgow-west-15368400
15:36
<annevk>
kennyluck: I don't want them to change necessarily; I'm just explaining my position...
15:37
<annevk>
kennyluck: feel free to jump in though
15:38
<annevk>
kennyluck: I don't have much more to say to him
15:56
<foolip>
annevk, what's the drama that got CC'd to the unicode list?
15:57
<foolip>
I tested Opera, Firefox and Chromium yesterday and they didn't agree on F8 80 80 80 80
15:57
<foolip>
but then I restrained myself from entering the debate :)
16:05
<dglazkov>
good morning, Whatwg!
16:07
<annevk>
foolip: utf-8 changed at some point and not all browsers updated
16:07
<annevk>
foolip: and Unicode allows several forms of utf-8 error handling
16:07
<annevk>
foolip: Opera/Gecko are getting patched
16:09
<foolip>
annevk, hmm, ok, no willful violation then?
16:09
<annevk>
more like restraining and keeping all encodings in one spec
16:10
<annevk>
foolip: see http://mail.apps.ietf.org/ietf/charsets/msg02054.html
16:10
<gsnedders>
jgraham: There are better stories about that. Highest and lowest life expectancies in Scotland are in Glasgow, about a mile apart.
16:12
<foolip>
annevk, mkay
16:18
<kennyluck>
annevk, is http://www.iana.org/assignments/charset-info still the right info to get subscribed to the list? I did what it says but got no response.
16:19
<annevk>
kennyluck: maybe it takes a while?
16:19
<kennyluck>
hmm… ok
16:20
<annevk>
kennyluck: was your email body exactly "SUBSCRIBE IETF-CHARSETS" ?
16:20
<kennyluck>
annevk, yes, and my Subject: was "subscribe".
16:21
<annevk>
I guess that should work
16:21
<annevk>
I no longer have any message to ietf-charsets-request
16:31
<jgraham>
gsnedders: But I bet the low life expectancy is amongst the poor and socially deprived. You're a student and therefore poor and studying CS and therefore socially deprived
16:32
<Ms2ger>
Zing.
16:32
<gsnedders>
jgraham: But I live in Hillhead, which is one of the well-off parts of Glasgow.
16:33
<smaug____>
dglazkov: did you see my question yesterday about setupEvent
16:33
<jgraham>
Two things 1) dammit I forgot to start sshd and 2) shouldn't you be either studying or partying?
16:34
<Ms2ger>
Or both?
16:34
<gsnedders>
jgraham: 2) just stopped studying :P
16:59
<dglazkov>
smaug____: oh. Sorry. setupEvent is just a helper that wires up:
16:59
<dglazkov>
smaug____: a) "onfoo" property for an event
17:00
<dglazkov>
b) "onfoo" attribute for the event
17:01
<smaug____>
ah, hmm
17:01
<smaug____>
dglazkov: it isn't explained
17:01
<smaug____>
I assume onfoo would be somewhere in the prototype
17:02
<dglazkov>
smaug____: yeah, I think I added it after some conversation with someone.
17:02
<smaug____>
dglazkov: why is it needed?
17:03
<dglazkov>
smaug____: just to help people with setting up events on their custom elements. This is tricky stuff to get right and seems like a nicely repeatable set of steps.
17:04
<smaug____>
dglazkov: I'm going through this all now...
17:04
<smaug____>
dglazkov: decorator seems to be very limiter
17:04
<smaug____>
limited
17:04
<smaug____>
especially its event handling
17:04
<smaug____>
you can't know the actual event target
17:05
<smaug____>
also listen() feels very heavy weight
17:06
<smaug____>
I kind of like the support for nested shadow trees
17:06
<dglazkov>
smaug____: yep. That's intentional, since the decorator are transient, so we don't want to be reaching into the DOM that may or may not be there
17:06
<smaug____>
dglazkov: I'm having hard time to figure out any real use cases for such decorator
17:07
<Ms2ger>
Who needs those anyway ;)
17:07
<dglazkov>
smaug____: ask sicking. He really wants decorators. I am ambivalent about them.
17:08
<smaug____>
indeed. We just design APIs, we don't use them :)
17:08
<smaug____>
I want decorators, but not the limited way
17:08
smaug____
waits sicking to be back from vacation
17:09
smaug____
still can understand, perhaps his English is just bad... vacation ? What is that
17:10
<dglazkov>
smaug____: I think today decorators are the least stable idea in the whole Web Components universe.
17:11
<smaug____>
right
17:11
<dglazkov>
smaug____: the shadow dom has a spec, the templates have a spec, the custom elements I already have a polyfill for (and will start working on spec next week), but decorators...
17:11
<smaug____>
custom events is another rather ... strange
17:12
<smaug____>
createElement("foo").localName != "foo"
17:12
<dglazkov>
custom elements you mean?
17:12
<smaug____>
er, oops
17:12
<smaug____>
right
17:12
<zcorpan>
localName should be "foo"
17:12
<dglazkov>
no, the createElement("foo").localName will always be "foo"
17:13
<dglazkov>
you can setAttribute("is", "x-foo") to make it a custom element
17:13
<dglazkov>
I have more of a problem with the "is" attribute, but Hixie and annevk argued strongly against introducing local semantics into HTML documents with actual custom tags.
17:13
<smaug____>
per documentation createElement("foo") may create something else
17:13
<zcorpan>
is there an .is IDL attribute that reflects is=""? (is that web-compatible to expose?)
17:13
<dglazkov>
so I am going along with
17:14
<smaug____>
var b = document.createElement("x-fancybutton"); alert(b.outerHTML); // will display '<button is="x-fancybutton"></button>'
17:14
<Ms2ger>
zcorpan, it's called "was" ;)
17:14
<smaug____>
so, local name is button
17:14
<zcorpan>
srsly? :-)
17:14
<Ms2ger>
No :)
17:14
<dglazkov>
smaug____: that's a bug in the explainer.
17:14
<smaug____>
aha :)
17:14
<dglazkov>
smaug____: :)
17:15
<smaug____>
makes it a bit hard to review this all ;)
17:15
<Ms2ger>
y u no right bugfree code?
17:15
<smaug____>
I'm trying to figure out what I think of this all, and whether something should be implemented in Gecko
17:15
<dglazkov>
smaug____: I started writing it completely bug-free, but somehow that didn't work.
17:16
<zcorpan>
"var b = document.createElement("x-fancybutton"); alert(b.outerHTML); // will display '<button is="x-fancybutton"></button>'" wat?
17:16
<Ms2ger>
Objection! Alleged x-fancybutton!
17:17
<dglazkov>
this is a carryover from the custom tags idea, where instead of using is attribute, we just had <x-fancybutton>
17:17
<smaug____>
ah
17:18
<zcorpan>
i thought that would be an actual element called "x-fancybutton", not magically turn into a different element with an attribute
17:18
<dglazkov>
zcorpan: I mentioned earlier that this is a bug in the explainer.
17:18
<zcorpan>
oh
17:18
<dglazkov>
zcorpan: there's even a nice button to file it :P
17:19
<zcorpan>
i'm just leaving irc remarks to irc remarks :-P
17:19
<Ms2ger>
A fancy one?
17:19
<dglazkov>
Ms2ger: well... for some definition of fancy
17:20
<dglazkov>
:)
17:20
<dglazkov>
it might help looking over these:
17:20
<smaug____>
dglazkov: how does element.content work?
17:20
<dglazkov>
https://github.com/dglazkov/Web-Components-Polyfill/tree/master/samples
17:20
<smaug____>
does it deserialize the content of element when used ?
17:21
<dglazkov>
smaug____: is this for HTML templates?
17:21
<smaug____>
er, template.content
17:21
<smaug____>
so, yes, templates
17:21
<dglazkov>
smaug____: it's spec'd here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#template-element
17:22
<dglazkov>
smaug____: it's an accessor returning a DocumentFragment
17:23
<smaug____>
dglazkov: but when is that documentfragment created ?
17:23
<smaug____>
and is it cached ?
17:24
<dglazkov>
smaug____: it's created when parsing
17:24
<dglazkov>
smaug____: and yes, it exists as one instance.
17:24
<smaug____>
so, no caching ?
17:24
<smaug____>
er
17:24
<dglazkov>
smaug____: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization
17:24
<smaug____>
caching
17:25
<dglazkov>
smaug____: yes.
17:25
<smaug____>
" the code property must be initialized in .."
17:25
<smaug____>
what code ?
17:26
<dglazkov>
duurrrr
17:26
<dglazkov>
I clearly meant "content" property :)
17:27
<dglazkov>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16810
17:28
<smaug____>
thanks
17:33
<dglazkov>
zcorpan, smaug____: also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16811 for the createElement.
17:38
<zcorpan>
thanks
17:41
<zcorpan>
anyone know how to change the default font size in ie9?
17:43
<zcorpan>
afaict there isn't a setting for it
17:48
<zcorpan>
ok so opera and ie don't have the font size quirk, so i'm commenting it out and hope webkit and gecko are willing to drop one of the font size tables
17:49
<Ms2ger>
File a bug :)
17:51
<zcorpan>
it's pretty bad that we don't have interop on <font size> sizes
17:55
<zewt>
what does interop even mean for font sizes? you'll always have user-specified minimum font sizes and other variations in the way
17:58
<annevk>
ooh
17:58
<annevk>
is the stuff that makes monospace fonts render smaller in Gecko?
17:59
<annevk>
latest argument from Shawn reads as if he thinks we ought to implement ISO HTML
18:00
<zcorpan>
zewt: ignoring minimum font sizes and assuming default font size of 16px, <font size=1..7> results in different computed font-size in opera/ie/webkit&gecko
18:00
<zcorpan>
(i think webkit and gecko are the same)
18:02
<zcorpan>
Ms2ger: https://bugzilla.mozilla.org/show_bug.cgi?id=747464
18:05
<zcorpan>
annevk: no, this is about <font size=1..7> and css font-size:xx-small..xx-large having different results in quirks mode and standards mode
18:05
<zcorpan>
though smaller monospace is something that needs to be sorted out as well
18:07
<zcorpan>
(the quirk doesn't result in different sizes for text where the default size is 16px because the tables have the same values for the 16px row)
18:08
<zcorpan>
(whereas the 13px row is different between the two tables)
18:20
<zcorpan>
TabAtkins: in the introduction you say "ident" but in the algorithm you say "identifier"
18:29
<Hixie>
Philip`: when people argue that we shouldn't support old things, one thing to bring up is that one of html's other goals is to make it possible for archeologists 1000 years from now to implement a browser and view today's content as it was intended
18:29
<Hixie>
Philip`: i.e. that it is preserving our heritage
18:30
<hober>
exactly
18:34
<Philip`>
Hixie: That doesn't seem like a very convincing argument for most web specifications, unless there was some effort to archive the server setups and databases of dynamic sites
18:35
<Hixie>
i'm specifically talking in the context of the guy saying we should drop <xmp>
18:35
<Hixie>
i.e. parser
18:36
<Hixie>
it is indeed only particularly helpful for static docs
18:36
<Philip`>
Currently the best efforts are just archiving the static page output (with archive.org etc), so any site that does non-trivial script manipulation is likely to break because of the lack of a server rather than because of lack of interoperability in the script APIs
18:36
<Hixie>
yup
18:36
<zewt>
i don't find that very compelling; for one thing, i don't think it's every browser's job to support things merely for historical value, and for another, if that's really what someone wanted to do, presumably they could also install a browser from the same era
18:36
<Philip`>
and for static documents, you can extract pretty much all of the information just by deleting all tags and looking at the text that remains
18:37
smaug____
doesn't trust anything digital to preserve more than few decades
18:37
<Philip`>
so future archaeologists will strip out most of the tags and stick the remaining text into an indexed database that they can analyse
18:38
<zcorpan>
TabAtkins: the dimension state doesn't append characters to the token's representation
18:39
<Philip`>
and archaeologists from the year 3000 are unlikely to get given the funding to implement an entire web browser, when they can get 90% of the value for massively less effort
18:40
<Hixie>
annevk: the url query thing is specced in html iirc
18:41
<Hixie>
Philip`: i have no idea if anyone in 3000 will care or not, or what their capabilities will be. i just want to make sure that they can do it.
18:41
<Hixie>
annevk: oh nevermind i misunderstood
18:43
<zcorpan>
ok made quirks mode use css3-syntax terminology
18:46
<Philip`>
Hixie: If you calculate the economic cost of spending effort on future-compatibility now, and then add the compound interest on that over the next thousand years, that sounds pretty expensive and would need a good chance of providing massive value to be worthwhile
18:47
<Hixie>
the incremental economic cost is zero since we need to do the work anyway to promote interoperability today
18:48
<Hixie>
also that argument excludes the cost term for moral imperative
19:29
<zcorpan>
hsivonen: jgraham: WDYT about https://www.w3.org/Bugs/Public/show_bug.cgi?id=16807 ?
19:33
<zcorpan>
ok who'll be the first to write a text editor in webgl?
19:34
<zcorpan>
because then i want to be able to change the blinking rate of my caret
19:52
<TabAtkins>
zcorpan: I have no idea why I thought that in-string escaping behavior was different than escaping behavior elsewhere. I'll fix that.
19:57
<zcorpan>
TabAtkins: lemme know if quirks mode is bogus with the new text
19:58
<zcorpan>
nice https://bugzilla.mozilla.org/show_bug.cgi?id=747485
19:59
<TabAtkins>
zcorpan: The dimension thing is intentional - the unit, unlike the number, keeps track of all the input characters.
19:59
<TabAtkins>
So you can fully recover the input (modulo escapes) from the representation + the unit.
20:00
<zcorpan>
oh. ok.
20:00
<TabAtkins>
What should I be reviewing about the quirks mode spec?
20:03
<TabAtkins>
Oh, I see - you explicitly link into my spec now. Nice. ^_^
20:05
<zcorpan>
fixed the dimension thing
20:06
<zcorpan>
maybe i can drop the "signed" thing now, not sure
20:07
<TabAtkins>
Yes, number and dimensions parse a leading +/- as part of their token.
20:08
<zcorpan>
and in case of identifier, it doesn't matter if it replaces the token because the delim token will mean the value is invalid anyway
20:08
<TabAtkins>
Yes.
20:11
<zcorpan>
fixed
20:21
<zcorpan>
TabAtkins: "U+0027 APOSTROPHE (‘)" in URL state has the ")" enclosed in <code class="css">
20:22
<zcorpan>
(and smart-quoted the ')
20:22
<TabAtkins>
Ah, whoops. All occurences of that character do.
20:24
<TabAtkins>
Fixed.
20:24
<TabAtkins>
And your quirks algorithm seems fine now.
20:25
<zcorpan>
cool, thanks
20:31
<Ms2ger>
zcorpan, I assume Opera would be happy to make the <u><font color> quirk apply in all modes?
20:32
<zcorpan>
sure
20:42
<TabAtkins>
MikeSmith: Could you add a "Syntax" component to bugzilla for CSS? I'm the contact, spec is at at http://dev.w3.org/csswg/css3-syntax/
21:36
<zcorpan>
TabAtkins: still one "ident" lurking
21:43
<TabAtkins>
Damn!
21:44
<TabAtkins>
What section is it in?
21:44
<zcorpan>
3.4. Tokenization
21:44
<zcorpan>
third para
21:45
<Yuhong>
<kennyluck> annevk, I think when you are having those debates with Shawn Steele, you should be clear that what you like MS to do is to change the encoder/decoder *used in IE*, not the system encoder/decoder. I have the feeling that Shawn knows nothing about IE.
21:45
<Yuhong>
AFAIK, IE uses the MLang library that is part of Windows.
21:47
<Yuhong>
Currently.
21:48
<Yuhong>
There are several system encoders/decoders in Windows.
21:49
<Yuhong>
http://blogs.msdn.com/b/michkap/archive/2005/07/26/443375.aspx
21:57
<Yuhong>
BTW, Vista has entered extended support recently which mean no more IE upgrades!
21:57
<Hixie>
TabAtkins: you aware of any plan to make 'white-space' have a value that works like 'normal' but optimises for equal line lengths?
21:58
<TabAtkins>
Heh, you're the third person asking about that this week.
21:58
<TabAtkins>
Oh wait, that's something different.
21:58
<TabAtkins>
Explain?
21:58
<TabAtkins>
Isn't that the definition of "text-align:justify;"?
21:59
<Hixie>
text-align:justify doesn't affect where words wrap, right?
21:59
<Hixie>
just the spacing between words
21:59
<zewt>
sounds like you're talking about the thing vtt wants
21:59
<Hixie>
i mean something like if i write "foo foo foo bar" it turns into "foo foo\nfoo bar" not "foo foo foo\nbar"
21:59
<TabAtkins>
Okay, that's nothing to do with white-space.
21:59
<Hixie>
zewt: yeah, your e-mail about it from december is what triggered my question
22:00
<TabAtkins>
But yes, I've had people ask about it this week, and pinged fantasai about it.
22:00
<zewt>
Hixie: there's some newer discussion (don't know if there's any new content, though)
22:00
<TabAtkins>
The obvious answer is "it's expensive on general web content".
22:00
<zewt>
no particular plans or anything since it's all on the webvtt list, which isn't where that would be done anyway
22:00
<Hixie>
zewt: i go through mail in order
22:00
<Hixie>
TabAtkins: k
22:00
<Hixie>
TabAtkins: should i just do a custom thing for webvtt then?
22:00
<zewt>
TabAtkins: but not really, like we discussed :)
22:01
<zewt>
(that is, it's not expensive if you don't try to do it "perfectly" and use the reasonable-approximation algorithm i suggested)
22:01
<TabAtkins>
But it's not difficult, and for WebVTT content it should be fast.
22:02
<Hixie>
TabAtkins: (seems to be 'white-space'-related to me, it controls where line breaks are put in. but i guess it could be a new property also, or a new keyword on text-align or something.)
22:02
<TabAtkins>
When you get down to it, it's about controlling the length of the last line relative to the other lines.
22:02
<TabAtkins>
Since, assuming normal wrapping, *all* the lines (except the last) are the same length.
22:03
<TabAtkins>
And being able to control wrapping to ensure that, say, the last lines of paragraphs are always >20% of the paragraph width is already useful.
22:03
<zewt>
TabAtkins: i guess that's one way of looking at it, but it affects all lines (not just the last) so it feels sort of an unnatural way of explaining it
22:03
<TabAtkins>
Making the requirement be "100% of the width" works just as well.
22:04
<TabAtkins>
zewt: I know. :/
22:04
<zewt>
that's sort of interesting--you could say "min-last-line-width", which is currently 0 (no requirement), 100 would mean "balance all lines", and you could turn the knob between those
22:04
<TabAtkins>
Yeah.
22:05
<TabAtkins>
I forget what the property's name was, but it used to be in Text.
22:06
<zewt>
(don't know if the approximate algorithm I sketched out could be made to do that)
22:06
<zewt>
i suppose it could
22:07
<zewt>
(i haven't tried implementing that in a real renderer and using it on real text, so I'm not 100% sure it'll actually work well in practice ... intuitively i think it will, though, at least for VTT-caption-size blocks of text)
22:07
<zewt>
i guess i could try faking it up with HTML
22:07
<TabAtkins>
Do it!
22:08
<zewt>
do eet
22:08
<TabAtkins>
You can even get exact width data - just measure a bunch of <span>s filled with characters.
22:08
<zewt>
i think i can do it just by adjusting the width of the container (reduce the width until just before the height starts increasing)
22:08
<Hixie>
all i want to do is change where hte line breaks go, i don't really care about this more complicated stuff :-)
22:09
<Hixie>
TabAtkins: i think it's a white-space issue because in webvtt you either hard-wire the line breaks or you want the lines equally long
22:10
<TabAtkins>
It's not really - white-space is about the treatment of the actual whitespace characters in the markup.
22:10
<TabAtkins>
And it's kinda weird to have a value that means "based on this layout algorithm, treat some of the whitespace as linebreaks, regardless of what it was originally".
22:10
<Hixie>
TabAtkins: right, and the control is whether line breaks in the markup should be treated like 'pre-wrap' or 'normal with special line balancing'
22:11
<TabAtkins>
That "with special line balancing" has nothing to do with the linebreak in the markup.
22:11
<Hixie>
anyway like i said i don't really mind which property we put it on, my concern is just that we put it somewhere
22:11
<Hixie>
should i just do it in webvtt?
22:12
<Hixie>
or is there something i can point to?
22:12
<Hixie>
or will be able to soonish?
22:12
<TabAtkins>
What would "do it in webvtt" imply?
22:12
<Hixie>
adding text here: http://dev.w3.org/html5/webvtt/#webvtt-cue-text-dom-construction-rules
22:12
<Hixie>
er, here: http://dev.w3.org/html5/webvtt/#the-'::cue'-pseudo-element
22:13
<TabAtkins>
I mean would it involve making up a property?
22:13
<zewt>
seems like white-space is just a shortcut for text-space-collapse + text-wrap, and this would actually be a text-wrap property (whether or not it happens to have a white-space shortcut of its own)?
22:14
<Hixie>
TabAtkins: well i was just gonna make it work based on the white-space property, for webvtt :-)
22:15
<TabAtkins>
Oh, so that white-space:normal just had the special behavior?
22:15
<Hixie>
basically
22:15
<TabAtkins>
If that "basically" is "exactly", sounds fine.
22:15
<zewt>
huh
22:15
<Hixie>
but maybe by just inventing a new keyword and making that the ua.css default for ::cue
22:15
<zewt>
webvtt shouldn't have magic differing behavior for existing CSS properties, right?
22:15
<TabAtkins>
New keyword isn't fine, because *this isn't a behavior that white-space shoudl control*.
22:16
Hixie
shrugs
22:16
<Hixie>
either way is fine by me, i just need to know what to do :-)
22:16
<zewt>
i'm not at all familiar with css specs--is http://dev.w3.org/csswg/css3-text/#white-space real or imaginary?
22:16
<Hixie>
zewt: css3 text in general is imaginary
22:16
<TabAtkins>
zewt: Quite real.
22:16
<zewt>
you two aren't helping :)
22:16
<TabAtkins>
That property is real.
22:17
<zewt>
according to that, it looks like this belongs as "text-wrap: balanced", and whether white-space also has a new shortcut for it or not is secondary
22:18
<TabAtkins>
text-wrap is okay if you don't plan to have any additional control.
22:19
<TabAtkins>
Though it would be compatible to have the eventual min-last-line-length property only work if text-wrap is 'normal'.
22:19
<Hixie>
if it's a separate property you'd also want it to work with things like pre-wrap
22:21
<TabAtkins>
Yes, "white-space:pre-wrap;" decomposes to "text-wrap:normal; text-space-collapse: preserve;"
22:21
<TabAtkins>
So it's compatible to swap out text-wrap for "balanced" or something.
22:21
<Hixie>
ok
22:21
<Hixie>
so this is all fine except text-wrap doesn't really exist as far as i can tell
22:21
<Hixie>
i mean it's been specced for like a decade and no browser has shown any interest to implement it, no?
22:22
<TabAtkins>
Good for you, then. You can just spec it for yourself with only two values.
22:24
<Hixie>
TabAtkins: i don't expect implementors to implement a property just for webvtt, given that it would have implications on all of css
22:24
<TabAtkins>
I'm unsure why you think a new value for an existing property is any different.
22:25
<Hixie>
i dunno, seems like keywords get implemented more easily
22:25
<Hixie>
i could be wrong about that
22:25
<TabAtkins>
They're basically identical from an implementation standpoint.
22:26
<Hixie>
hmm
22:26
<Hixie>
well i guess i can spec text-wrap
22:26
<Hixie>
with 'normal' and 'balanced'
22:37
<Hixie>
actually i don't think text-wrap is the right place
22:37
<Hixie>
it's another axis, really
22:38
<TabAtkins>
HAH
22:38
<Hixie>
that is only applicable at the block level
22:38
<Hixie>
so i'm kinda back to a new keyword on 'white-space'
22:38
<zewt>
TabAtkins: https://zewt.org/~glenn/balanced-wrapping.html it does seem to work fairly well
22:38
<zewt>
(obviously that's a dumb-slow way of doing it)
22:39
<Hixie>
basically a new column to the table in 3.4
22:39
<TabAtkins>
Hixie: white-space is a shorthand, so it's still not appropriate as a place to hang new values. ^_^
22:39
<Hixie>
TabAtkins: it's a shorthand only in theory
22:54
<Hixie>
annevk: you around? character encoding heuristic detection for webvtt: something we can point to your spec for? no?
22:55
<Hixie>
annevk: also are you doing anything for script detection for font selection?
22:55
<Hixie>
TabAtkins: do you know if the csswg is doing anything on script detection for font selection?
22:57
<zewt>
why would webvtt need encoding detection instead of being utf-8 only?
22:57
<TabAtkins>
More details? You want to check what font a specific element has?
22:57
<zewt>
Hixie: script detection--you mean @lang heuristics for CJK?
22:57
<Hixie>
zewt: yeah
22:58
<Hixie>
TabAtkins: i mean the way that browsers pick which language glyphs to use for CJK characters
22:58
<TabAtkins>
Oh! That kind of script.
22:58
<zewt>
(i've never heard of anyone taking that seriously; it's hard enough to convince people that being able to tag languages is useful in the first place, much less language heuristics)
22:58
<Hixie>
zewt: utf-8 only is probably what we'll do, i'm just exploring options
22:59
<zewt>
crazytalk
23:00
<TabAtkins>
Hixie: I think this is what we've got right now: http://dev.w3.org/csswg/css3-fonts/#language-specific-support
23:02
<Hixie>
TabAtkins: k. anyone working on that, do you know?
23:02
<zewt>
"If the ‘lang’ attribute is not defined, the default OpenType language system must be used." i doubt that'll ever happen with CJK ...
23:02
<TabAtkins>
Yeah, John Daggett.
23:02
<Hixie>
TabAtkins: k
23:02
<TabAtkins>
That's his only spec, and he lives in Japan, so I'm sure he'd be willing to tighten things up as necessary.
23:02
<Hixie>
zewt: since you are enthusiastic about the CJK problems there, do you want to post to the list about the problems with this being so underdefined? :-)
23:03
<zewt>
well, i don't have any *solutions*, unfortunately
23:03
<zewt>
basically @lang seems in exactly the same boat as default encodings: browsers end up having to use the user's language as part of figuring out the default, or else they get it wrong too often
23:04
<zewt>
which i hate, but like the encoding problem i have no idea how to fix it
23:04
<Hixie>
what do browsers do?
23:04
<Hixie>
that's what the spec should say, at a minimum
23:05
<zewt>
okay not sure what just happened
23:06
<zewt>
i'd need to refresh my memory, but I'm pretty sure IE has defaults depending on the user's browser, and I think FF does the same (with the browser language)
23:07
<rafaelw_>
Hixie: I'm working on a local patch for template element and I'm starting to wonder if it isn't smart to separate two concerns here: (a) context-free parsing, and (b) declaring inert DOM structures.
23:08
<zewt>
which has the same problem as when encodings do that: Japanese people see Japanese glyphs if they don't specify anything at all, so they don't specify anything, resulting in Japanese pages only looking right on Japanese-locale systems (vs. zh-TW/zh-CN)
23:08
<rafaelw_>
Ojan said (I think) that he should it would be reasonable to add something like innerHTML to DocumentFragment which would acomplish (a). I'm presuming there has been discussion of this in the past. What's your sense?
23:09
<rafaelw_>
(context-free parsing, specifically for HTML -- I'm assuming this issue is intrinsic to HTML parsing, but maybe I'm wrong).
23:18
<rafaelw_>
Hixie: did you see my question (looks like you might have quit & rejoined)?