00:01
<SamB>
the one thing I've liked about it in the past is that I can actually get more-or-less a whole stack trace for code compiled with it
00:01
<SamB>
but maybe I could do that with an up-to-date GDB, too
00:03
<SamB>
(with GCC on windows, I've had to resort to stuff like using WinDbg alongside GDB and/or binutils)
00:04
<SamB>
(where WinDbg can unwind to my code -- and very likely also through it -- and GDB or binutils can help me with the addresses/name mappings)
00:07
<SamB>
(hmm, I guess intelisense is also kind of cool ...)
00:07
<SamB>
(but not cool enough to really want to deal with cl.exe ...)
00:08
<SamB>
(or, well, the compiler proper's probably in DLLs now ...)
00:09
<SamB>
Hixie: isn't the outline for http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html kind of nonsensical?
00:11
<Philip`>
zewt: "#define _CRT_SECURE_NO_WARNINGS" has worked in all the cases I've seen so far
00:12
<SamB>
do they seriously have a read_s?
00:13
SamB
reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=26012
00:15
gsnedders
finally has a moment in which he thinks having text nodes is a good distinction from strings
01:16
<Domenic>
Hah, I like how in the WebKit source code there's an actual callTheAdoptionAgency(token); line
01:19
<SamB>
Domenic: well how would YOU name something that implements "call the adoption agency"?
01:50
<caitp>
"activateTerribleDesignDecision()"
02:01
<caitp>
seriously, who ever came up with that reparenting scheme... SMH ._.
02:37
<gsnedders>
caitp: see the acknowledgements section of the spec; Dave Hyatt
02:37
<gsnedders>
caitp: and if you start with the requirement that the DOM must be a tree, it's not clear you can do much better :(
02:38
<caitp>
gsnedders, this discussion has been had with hixie --- the DOM doesn't break when things don't get reparented, you can see this by dynamically inserting arbitrary content at places where it would ordinarily be reparented during parsing
02:39
<caitp>
it was a mistake to ever decide the DOM needed to reparent things, and it turns out to be very hard to fix that mistake ._.
02:39
<caitp>
but I don't like to name names when mocking terrible design decisions
02:40
<caitp>
people did it wrong before, and I guess we're stuck with it forever :(
02:40
<gsnedders>
But if you don't reparent you don't get a DOM that renders correctly, no?
02:41
<caitp>
you get a DOM that renders the way you expected it to be rendered when you authored your content wrong
02:42
<caitp>
the reparenting thing A) complicates things for no good reason, and B) makes things like custom elements slightly harder to implement correctly without the use of hackish nonsense like is=*
02:43
<caitp>
all to avoid breaking some awful smut website, I mean really
02:43
<gsnedders>
Plenty would argue "to avoid breaking some website" is a good reason. :)
02:43
<caitp>
people were not thinking when they decided this was something that needed to happen, but it's too hard to fix it =(
02:46
<gsnedders>
But, eh, the ship sailed when it came to misnested content tags before I could speak (probably).
02:48
<caitp>
from my perspective, my generation shouldn't have to pay for mistakes made by the generation that came a decade or two before, we should be fixing their broken crap
02:48
<caitp>
but herr ian disagrees
02:49
<gsnedders>
meh, plenty of evidence that breaking websites leads web browsers to lose marketshare and not websites being fixed
02:50
<caitp>
from my perspective, that's not a real excuse, if it leads to future work having to satisfy earlier, broken work
02:50
<caitp>
but people have their priorities, I guess
02:50
<caitp>
I just think they're getting it wrong in this case
02:50
<gsnedders>
convince the browser vendors to lose their marketshare, I guess
02:50
<gsnedders>
And there's again plenty of evidence what's in a spec doesn't really effect what browsers do in terms of breaking sites
02:51
<caitp>
that is certainly true
02:51
<caitp>
but the fact that the reparenting scheme lives in the spec sort of validates the decision to include broken stuff in the browser
02:52
<gsnedders>
Only difference the spec dropping it would make is the spec would cease to have implementations
02:53
<caitp>
if all vendors decided to ignore it
02:53
<gsnedders>
which they will
02:53
<caitp>
I don't think you can say "they will"
02:53
<caitp>
there are a lot of implementations out there
02:54
<gsnedders>
well, any impl with any real number of users will ignore it
02:55
<caitp>
I'm not sure about that, I don't think fixing that particular part of brokenness would hurt marketshare that much for a mainstream browser
02:55
<caitp>
and it would be temporary
02:56
<caitp>
you know why it's temporary, because people have their browser of choice, it's part of their identity, it becomes who they are!
02:56
<caitp>
that sounds silly, but it's not that much of an exaggeration, people have preferences for this stuff
02:56
<caitp>
pretty strong, irrational preferences
04:21
Hixie
runs into the fact that the stack of open elements is sometimes randomly mutated
04:22
<Hixie>
bummer
04:22
<Hixie>
that's gonna be exciting.
05:18
<Hixie>
hey someone double-check me here. In "push onto the list of active formatting elements", where the spec says "list markers", it should say "scope markers", no?
09:19
<jgraham>
Hixie: AFAICT there you use "list marker", in the definition above you use "scope marker" and everywhere else you use "marker"
16:08
<Hixie>
jgraham: k, that's what i concluded too
16:15
<jgraham>
Hixie: FWIW I think "scope marker" is a bad name since it requires a note that it doesn't correspond to the other notion of "in scope"
16:41
<Hixie>
jgraham: yeah...
16:46
<Hixie>
ok, renamed them all to just "marker", that's unambiguous enough
16:46
<Hixie>
also, made them all cross-refs
16:50
<jgraham>
Hixie++
23:50
<gsnedders>
http://anolis.gsnedders.com/ seems pretty silly
23:50
<gsnedders>
Why doesn't that just redirect?
23:50
<gsnedders>
o_O