From: Kevin Carhart <kevin@carhart.net>
To: Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@lists.the-brannons.com
Subject: Re: [edbrowse-dev] attributes
Date: Sat, 29 Jun 2019 18:14:29 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.1906291759550.226308@carhart.net> (raw)
In-Reply-To: <20190529190858.eklhad@comcast.net>
Hi Karl
Well sure enough.. I was unaware that there was any such distinction, to
tell apart an attribute set at create time by createElement, from one that
is explicitly set by setAttribute. Ian the acid3 author has a comment
right there on 61. You assert that p.hasAttribute('class') must return
false, and if it didn't, the diagnostic string says "element had attribute
on creation." I assume you're interpreting the acid tests correctly since
you pored over the assert() conditions. That would tell you what types of
distinctions matter.
Maybe there is a JS problem in maersk where it is supposed to be setting
id using setAttribute, earlier on. That would be a plausible
alternative hypothesis that threads the needle, and returning null would
be correct.
On Sat, 29 Jun 2019, Karl Dahlke wrote:
> I could use your help here.
> Line 1680 is there because acid test 17 says that getAttribute of id should not return the id unless it was set by setAttribute, or that is the way I interpreted it at some point.
> These various implicitMember functions are suppose to be exceptions, times when you don't getAttribute unless you did an earlier setAttribute.
> Same for "class" acid test 61.
> Maybe I'm not interpreting the acid tests right,
> maybe I just need someone else to take a second look.
>
> I have acid3 in the github source, it is my version of the original page, but I think it is true to that page, with my comments and changes of course.
>
> Karl Dahlke
>
prev parent reply other threads:[~2019-06-30 1:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-29 20:21 Kevin Carhart
2019-06-29 23:08 ` Karl Dahlke
2019-06-30 1:14 ` Kevin Carhart [this message]
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.DEB.2.21.1906291759550.226308@carhart.net \
--to=kevin@carhart.net \
--cc=edbrowse-dev@lists.the-brannons.com \
--cc=eklhad@comcast.net \
/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).