From: Kevin Carhart <kevin@carhart.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] suggested additions
Date: Mon, 4 Sep 2017 18:16:35 -0700 (PDT) [thread overview]
Message-ID: <alpine.LRH.2.03.1709041801030.28685@carhart.net> (raw)
In-Reply-To: <20170804101202.eklhad@comcast.net>
Thanks for the feedback.
>
> Yes but not as simple as it seems.
Thank you for implementing (2). Yes, I take your point that it goes
deeper than the place I wanted to put my one-liner in decorate.c.
> Then, I'm not sure what contentWindo means, but I suppose the window of the frame, rather than the document of the frame, check for specifications.
> Even that doesn't work with your example js.
>
> doc = ( iframe[ 0 ].contentWindow || iframe[ 0 ].contentDocument
> ).document
>
> So we're grabbing window.document or document.document, the latter doesn't make any sense.
I know, I don't understand the idiom. I basically said "the latter
doesn't make any sense, but if we can supply the former, that appears to
be one of the two things it will accept." How does the parsing work if
you have a control structure that tests (a || b) and a is true and b is
illegal or raises a runtime? I sort of recall that this varies by
language, but is it plausble that some languages would test 'a', get a
true, and proceed?
I have one idea for why this code would be this way. Could it be a
superset of two mutually-exclusive browser-DOMs that the jquery author is
handling all in one line? For instance, you can't be both a firefox and
an IE/Edge at once. Maybe that line is designed as a catch-all that will
end up covering multiple client implementations. This still doesn't make
document.document make sense. I don't know.
>
> (7) Following on from Karl's exclusion of @ from the CSS selectors,
>
> Yeah this is ugly but I started it, so you may as well continue it.
> I do think regular expressions are more readable / intuitive, and powerful.
I agree, I just don't have all the tokens memorized so it slows me down.
I'm not sure I was getting ^ to work right, so I bailed out to a
different technique. This is fine. I think I'll submit 1,3,4,5 and 6 as
one, and then deal with writing these properly using .match and do 7 as a
second patch. I like regex. I'm not averse to it.
next prev parent reply other threads:[~2017-09-05 1:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-04 2:38 Kevin Carhart
2017-09-04 14:12 ` Karl Dahlke
2017-09-05 1:16 ` Kevin Carhart [this message]
2017-09-05 2:27 ` Karl Dahlke
2017-09-04 15:06 ` Karl Dahlke
2017-09-05 1:32 ` Kevin Carhart
2017-09-04 17:10 ` Karl Dahlke
2017-09-05 2:15 ` [Edbrowse-dev] contentWindow Kevin Carhart
[not found] ` <20170804223729.eklhad@comcast.net>
2017-09-05 2:58 ` Kevin Carhart
[not found] ` <20170804232757.eklhad@comcast.net>
2017-09-05 3:57 ` Kevin Carhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.03.1709041801030.28685@carhart.net \
--to=kevin@carhart.net \
--cc=Edbrowse-dev@lists.the-brannons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).