Re: [Edbrowse-dev] getAttributeNode / setAttributeNode

[Kevin Carhart <kevin@carhart.net>]

I don't think any of what you are doing is incorrect though.  There are 
multiple sub-projects going on at once almost!  It is very, very, very 
wonderful to parse and propagate style blocks and .css files.  It is a 
quantum leap, iframe support is a quantum leap, so I am in heaven.

So if we ourselves call qS almost like a private member that would not be 
exposed to pages, this is great.  We can call it anything we want.

There are two potential use cases for qS.

The same work that can do two kinds of jobs.  The first job is, we call qS 
ourselves, as part of I think a three step process to (a) parse css 
sections (b) identify and return the set of elements that the styles need 
to be doled out to (c) dole out the styles to that set of elements

I leapt ahead, without enough explanation of what I was on about. 
Because pages *also* call querySelector and 
querySelectorAll.  It's separate in some ways - it is separate from us 
being a web browser and doing an integral, fundamental thing with styles 
information.  It is more like the toolbelt of the web designer.  The web 
designer calls getElementsByTagName("blah") in one function and then calls 
querySelectorAll(":blah") or querySelectorAll(".blah") in the next.

One job is low level and internal, and the other job is high level and 
external, but they both use qS to process the selectors mini-language and 
then search the tree.  (Those terms "high level" and "low level" are so 
overloaded both in technical settings and regular society or whatnot that 
they are really useless.  But I hope you get what I'm describing.  If 
low-level is taken to mean, less about aesthetics, fundamental 
architecture of a web browser per se, that's the first job.  If high-level 
is taken to mean, scripters and designers who build websites, that's the 
second job.)

Does that make sense?  Sorry if by overlapping two use cases I made 
anything confusing.  It's like water rushing downstream because I am so 
excited about both of the scenarios!!




>> Sounds like I misunderstood though, and it should really be called 
>> querySelectorAll, but that's just a one line change if we want to do that.
>> Let me know if that's what we should do.
>
> Well.. I believe so, in the same way that we have apch, but pages by some 
> random web developer in the world expect to lock on to appendChild. It's the 
> DOM.  querySelector and querySelectorAll are part of the DOM as far as they 
> are concerned.  We just happen to be implementing them in open javascript.