00:00
<gsnedders>
I don't think you can, given the fact you can invoke AAA at any point.
00:00
<TabAtkins>
Just push the entire in-table contents into a stack until you hit </table>, looking for AAA-stuff and parsing appropriately. Then, emit <table> and start parsing the built-up in-table stack.
00:01
<gsnedders>
Yeah, that's the vague sort of approach I was thinking of for <html x><html b>
00:01
<gsnedders>
But I'm not sure you can share the stack with that of open elements.
00:01
<dglazkov>
I used to have a PDA. I had to put a couple of AAA's into it to make it work.
00:02
<TabAtkins>
Yeah, I'm not certain either. I'm not really familiar with nested-stack machines.
00:03
<gsnedders>
In fact, you almost certainly can't
00:03
<TabAtkins>
Well, I'm fairly certain that HTML is parsable by a LBA, since all actual computers are that.
00:04
<TabAtkins>
And we have bounds on the size that some stacks can grow.
00:04
<TabAtkins>
I guess we'd need to make sure that there aren't any unbounded stacks.
00:04
<gsnedders>
Stack of open elements is unbounded.
00:04
<TabAtkins>
Ah, right. There you go, then.
00:04
<TabAtkins>
All the way past CSG, I think.
00:05
<gsnedders>
Unbounded stacks can exist in an LBA
00:05
<gsnedders>
and in a PDA too
00:05
<gsnedders>
You only need a finite stack for a given finite input
00:05
<TabAtkins>
(btw, a two-stack pda is turing-equiv because the two stacks are equivalent to a single tape with a bidirectional head)
00:05
<gsnedders>
(Oh, duh)
00:06
dglazkov
sulks because nobody liked his joke
00:06
<TabAtkins>
Oh, wait. Let's see. Are there any stacks that grow faster than linear in the input size?
00:06
<TabAtkins>
The stack of formatting elements did at some point, I think.
00:06
<gsnedders>
No.
00:06
<TabAtkins>
Okay, then we're good.
00:06
<TabAtkins>
It's likely an LBA then.
00:06
<gsnedders>
At some point, yes. But it has a limit now.
00:06
<TabAtkins>
And thus a CSG.
00:07
<gsnedders>
It's going to get horrifically messy, but I think it's doable.
00:07
<TabAtkins>
Yes, definitely.
00:07
<gsnedders>
Yeah, we're definitely an LBA.
00:08
<TabAtkins>
Though, honestly, a proof of such just requires that it's (a) parsable by a turing machine, and (b) has no memory requirements that grow faster than linearly.
00:09
<Hixie>
i have no idea what the heck you are all talking about, but let me know if you come to a decision that affects the spec :-D
00:09
<Hixie>
dglazkov: if it helps, i thought it was amusing. :-P
00:09
<dglazkov>
yay!
00:09
<gsnedders>
Hixie: It mostly has implications on proving the correctness of implementations
00:11
<gsnedders>
TabAtkins: What I wonder is whether a nested stack will do
00:12
<TabAtkins>
Yeah, I'm not actually familiar with nested-stack, and the wikipedia article is minimal.
00:16
<gsnedders>
Oh well, next year I get to learn about grammar from two POVs at uni.
00:16
<gsnedders>
(From both a CS POV and a theoretical linguistics one)
00:18
<TabAtkins>
zewt: "This is the worst thing I've seen anyone say in here in a long time" sounds like a challenge.
00:18
<zewt>
heh
00:18
<zewt>
have at thee, archives
00:19
<TabAtkins>
Oh, I was just going to say something involving hitler and tentacles.
00:19
<zewt>
the world is desensitized to tentacle hitlers
00:20
<gsnedders>
Does foreign content make conforming content context-sensitive?
00:20
<gsnedders>
Hmmm
00:20
<TabAtkins>
Because it's allows arbitrary XML?
00:20
<TabAtkins>
If so: yes, or at least prevents it from being context-free.
00:20
<gsnedders>
Nah, nested stack will do.
00:20
<TabAtkins>
XML is *almost* context-free.
00:21
<zewt>
why does google docs always always break with multiple addresses
00:21
<TabAtkins>
If only they did end-tags by reversing the name of the tag.
00:21
<gsnedders>
TabAtkins: Doesn't it work if you just push the name of the element to the stack?
00:22
<gsnedders>
Why would you need to do it char by char?
00:22
<gsnedders>
AIUI XML is context-free.
00:22
<TabAtkins>
Because that's how I've typically seen grammars defined?
00:22
<TabAtkins>
Specifically, {ww | w in {a,b}+} isn't context-free.
00:23
<TabAtkins>
And thus, neither is {<w></w>}
00:23
<gsnedders>
Right, okay
00:23
<TabAtkins>
If you tokenize at a higher level, then sure.
00:23
<gsnedders>
Which is effectively what a nested stack parser does.
00:24
<TabAtkins>
Ok, that makes sense.
00:24
<TabAtkins>
Then... I suspect a nested stack parser would work.
00:25
<gsnedders>
Unless I'm misunderstanding.
00:27
<TabAtkins>
No, that makes sense given the minimal wikipedia definition.
00:32
<gsnedders>
So given scripting enabled...
00:33
<gsnedders>
We're a decider, as we halt.
00:33
<gsnedders>
Provably, the HTML5 parser will halt.
00:35
<gsnedders>
(Of course, the system as a whole is Turing complete, because the JS might not)
00:41
<gsnedders>
(Sad reality: I'm starting to wonder whether AAA is the best solution. But I guess I'll get murdered if I suggest that without a good reason for it.)
01:36
<TabAtkins>
Man, a 2-day delay in me getting webkit set up was caused by an e/i typo.
01:36
<TabAtkins>
;_;
05:46
<kennyluck>
annevk5, use data:text/html;charset=big5,%C7%B1%C7%AB%C7%E5 as an example and you'll see the difference.
05:47
<kennyluck>
(re. Gecko implementing a superset of CP950)
07:43
<annevk>
kennyluck: ah I see what you mean; I guess we'll go with the bigger table if it's not too much of a hassle, dunno
07:49
<kennyluck>
annevk, but this is not implemented in browsers besides Firefox so this is sort of a proprietary extension, though I guess it would be nice if IE can adopt it.
07:51
<annevk>
hmm, if only Gecko has it, it might be something they can consider removing...
07:51
<annevk>
or is it used?
07:51
<kennyluck>
It is used. This is an example → http://www.ptt.cc/bbs/C_Chat/index.html
07:54
<kennyluck>
Not so frequently though, basically Japansese kanas in big5. People rarely complain about this problem in other browsers so removing it doesn't harm much either…
07:58
<annevk>
kennyluck: interesting
08:02
<kennyluck>
I don't really get the bar as to what "breaks the web". The encoding detection step can obviously be arbitrarily complex just to save more pages...
08:05
<annevk>
kennyluck: it's a judgment call between complexity and making more pages work
08:44
<annevk>
kennyluck: any ideas on how to present those data tables btw and what the best location is to retrieve them?
08:44
<annevk>
kennyluck: I've currently done them as tables, but it might be better to just use arrays
08:45
<annevk>
all single-octet encodings currently defined are effectively arrays of 128 items
08:45
<annevk>
multi-octet encodings have arrays that are longer, but there are not that many
08:46
<annevk>
there's only one for Japanese for instance
08:49
<bga>
Google - total NIH :) replace all web related thechnologies to own, s/js/dart/ s/http/spdy/ ....
08:53
<kennyluck>
annevk, a button for copying into the clipboard I guess :) nobody reads the table itself anyway.
08:53
<kennyluck>
Is there a standard way to present such a table?
08:55
<kennyluck>
well, a space separated list would be the most reusable format I guess, like this → http://moztw.org/docs/big5/table/moz18-b2u.txt if IETF doesn't have a standard already.
08:55
<annevk>
oh good times
08:56
<annevk>
the default styling for <ol> makes it so that if you go over 9000 (actually 9999) you can no longer see the first digit
08:57
<kennyluck>
lol
09:00
kennyluck
is looking at the iconv source to find the biggest table → http://git.savannah.gnu.org/cgit/libiconv.git/tree/lib?id=3a33986e1d2c819dc2b8a84684e067cf177d1815
09:01
<kennyluck>
Is cns11643_inv used on the Web?
09:03
<kennyluck>
euc_tw… I guess it's not
09:03
<annevk>
http://git.savannah.gnu.org/cgit/libiconv.git/tree/lib/utf8.h looks buggy; still handles six octets
09:04
<annevk>
kennyluck: both Opera and Gecko support it I believe in incompatible ways, but also through iso-2022-cn (not sure how compatible it is there)
09:04
<kennyluck>
9000 seems enough, though I am still not convinced why we want to format it in HTML...
09:05
<annevk>
Japanese has an index of multiples of 94
09:05
<annevk>
so if that could somehow be nicely represented in HTML it might be a nice way for people to look up stuff
09:05
<annevk>
on the other hand, a long list of index -> codepoint could also work
09:06
<annevk>
in text/plain that is
09:07
<annevk>
kennyluck: would you say the single-octet encodings should not be represented as HTML either?
09:08
<kennyluck>
annevk, no.
09:08
<kennyluck>
I mean it should be presented as HTML.
09:09
<kennyluck>
I guess you should use the <details> element :p
09:11
<annevk>
for multi-octet tables?
09:11
<annevk>
that could work
09:12
<annevk>
still need a way to present them
09:12
<annevk>
94 characters per row is quite long :)
09:24
<annevk>
Larry Masinter: fighting silly registry policies since '98: http://unicode.org/mail-arch/unicode-ml/Archives-Old/UML013/0007.html
09:24
<annevk>
(and prolly before)
09:28
<kennyluck>
annevk, by the way, how do you know big5-hkscs is needed for the Web?
09:32
<annevk>
there's issues in various bug databases suggesting it is
09:33
<annevk>
though I think the way it works is that users use manual override or an extension or some such
09:33
<annevk>
I'd love to get more information on that somehow
09:38
<Ms2ger>
Hixie, fwiw, I'd also like to get div.impl highlighted, and I don't care about Workers/Websockets
10:48
<annevk>
there's various notes suggesting Gecko supports an eight octet sequence in euc-kr, but I cannot find how it's implemented :(
10:48
<annevk>
e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=9962
10:50
<annevk>
another thing that makes this difficult is that Gecko patches generated files rather than source files: https://bugzilla.mozilla.org/show_bug.cgi?id=134749 :/
10:53
<annevk>
although I guess the process is documented so it should be okay
11:10
<annevk>
hmm, iso-2022-kr looks like quite the mess
11:10
<annevk>
so surprising
11:47
<annevk>
can someone explain the purpose of ESC $ ) C in iso-2022-kr to me?
11:52
<annevk>
looks like it's meaningless
11:55
<annevk>
but adds a ton of complexity
12:17
<annevk>
so it seems Gecko only supports ESC $ ) C if it's at the beginning of the file and it will have zero effect
12:17
<annevk>
the effect is that you don't get to see ESC $ ) C on the screen
12:18
<annevk>
maybe we should just drop it altogether
14:10
<annevk>
whoa that XHR discussion blew up a bit
14:31
<espadrine>
dglazkov: in Web Components, do you plan on making templates have substitution slots as in http://infrequently.org/11/fronteers/fronteers.html#40 ?
14:53
<annevk>
kennyluck: http://w3techs.com/technologies/details/en-b5hkscs/all/all
14:54
<zewt>
"whose character encoding we know" there's a big caveat if ever I saw one. heh
14:55
<annevk>
http://i818.com/ and http://www.consumer.org.hk/website/ws_chi/ are still online and do indeed declare big5-hkscs
14:55
<zewt>
wonder how smart its charset guessing is (guessing big5 is probably fairly easy)
14:56
<annevk>
they also render fine in IE which reportedly treats big5-hk.. as label for big5
14:58
<annevk>
aah actually
14:58
<annevk>
IE does not render some characters correctly
14:59
<annevk>
I get boxes and UPA code points and in other browsers I get Unicode assigned characters
14:59
<annevk>
so I guess you need a HK Windows setup to render such a page correctly in IE
14:59
<annevk>
(but you'll still get into trouble if you copy data elsewhere)
15:53
<annevk>
okay, hkscs is for later
15:54
<annevk>
hkscs / gbk/gb18030 madness / and prolly nuking iso-2022-cn and euc-tw in a way similar to Chrome
15:54
<annevk>
oh and then utf-8 and utf-16
15:55
<annevk>
and the tables and the encoders
15:55
<annevk>
tralala
15:55
<Ms2ger>
Job security :)
15:55
<annevk>
nah, just good times :)
15:56
<zewt>
death to modal encodings
15:57
<Ms2ger>
s/modal/
15:57
<Ms2ger>
/
15:57
<zewt>
be sort of hard to do anything without *any* encodings
15:58
<annevk>
could certainly do away with the 99%
15:58
<Ms2ger>
#occupyiso-2022-cn
15:58
<zewt>
don't say that around F ms2 got there first
15:59
<annevk>
was that a joke in a different encoding?
16:05
<annevk>
btw Ms2ger / zewt, it's prolly good to stay nice to Jarred; he's fighting the good fight
16:05
<annevk>
a good idea*
16:05
<annevk>
gotta go now
16:05
<Ms2ger>
See you
16:31
<dglazkov>
espadrine: I am thinking about it. Please file a bug here: https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&blocked=14949&short_desc=%5BExplainer%5D%3A%20&product=WebAppsWG&component=Component%20Model
16:45
<hsivonen>
bold use of "assume" in https://www.w3.org/Bugs/Public/show_bug.cgi?id=15447
16:46
<zewt>
"planning to plan to" sure sounds like an academic
16:50
<Philip`>
"One of my design rules is that the agent may ignore parts of standards, if I deem those parts unnecessarily inelegant." - why bother trying to get the standard changed, then?
16:51
<zewt>
"i know better than the rest of the web, sit down everyone"
16:52
Philip`
wonders what would happen if there was an opportunity to redesign HTML from scratch without caring at all about compatibility, based on the lessons currently learnt from it
16:56
<Philip`>
(Also: "I am assuming that, ignoring GeoCities-era websites, usage in the wild is now limited to ad and tracking scripts." - maybe someone could point out that the page on which he is writing that comment uses document.write for useful functionality)
16:57
<Philip`>
(Maybe Bugzilla counts as GeoCities-era technology, though)
17:00
<hsivonen>
annevk: not usre if there's interest in standardizing chardet, but there is a paper that explains what it does, IIRC
22:53
<annevk>
hsivonen: k, guess I'll take a look once I've done everything else
22:53
<annevk>
which may take a while
23:04
<annevk>
Notes:
23:04
<annevk>
* use encoder / decoder as terms
23:05
<annevk>
* write as "The <dfn>gbk decoder</dfn> (<span>decoder</span> for <span>gbk</span>) is:" for easier referencing
23:06
<annevk>
* keep the single-octet tables, but use an external file in Unicode.org-style as normative format (maybe stripping 00-7E)
23:07
<annevk>
* see about using Unicode.org-style for the jis table (e.g. cp950) rather than an array
23:26
<annevk>
so as far as I can tell the only encoding not compatible with ASCII that made it into the new standard is utf-16
23:26
<annevk>
utf-16 is truly unique and evil
23:46
<Hixie>
hey anyone know if there's something that would cause <button>s in Firefox to magically sprout disabled="" attributes?
23:47
<smaug____>
sprout .. attributes?
23:47
<Hixie>
i have a <button> in a project i'm doing that doesn't have disabled="" in the markup, and nowhere in any of the scripts do i change that button's disabled state
23:47
<Hixie>
and if i set a dom breakpoint on attribute change it never fires for this button
23:47
<Hixie>
yet every now and then, it ends up having a disabled attribute
23:48
<smaug____>
I don't recall anything which might cause that
23:48
<Hixie>
weird weird weird
23:49
<Hixie>
doesn't happen in webkit as far as i can tell
23:49
<Hixie>
so i don't think it's my code
23:49
<Hixie>
but i can't see why it would happen otherwise
23:49
<Hixie>
i don't have any browser sniffing or anything that should make it different in different browsers
23:50
<smaug____>
any addons?
23:51
<smaug____>
Hixie: or does it happen only after reload ?
23:51
<Hixie>
Firebug, DOM Inspector, "Blank Tab Multivariate Test Addon 1.3", and "Test Pilot 1.2 (disabled)"
23:51
<Hixie>
everything i do is after reload, so it could be
23:51
<Hixie>
(i'm continuously reloading this project as i hack on it)
23:51
<smaug____>
does shift+reload help
23:52
<smaug____>
note, webkit doesn't have form state restoration thingie
23:52
<smaug____>
IIRC
23:52
<Hixie>
i usually reload with shift+command+r
23:52
<Hixie>
webkit does have form state restoration, but this isn't that, my code never sets disabled on the button
23:52
<smaug____>
right
23:58
<smaug____>
I don't see anything in Gecko which could cause that