david-mark-llc / jessie Goto Github PK

Should be getElementParentElement as written. Rendition #1 should degrade in IE5- and rendition #2 should include the additional logic to work in IE4-5 (likely not much call for that one these days).

Just as we parse description and degradation info, want to be able to pull (original) author name/email, organization/website from rendition comments. Haven't decided how/where I want to display the information yet (probably will hide/show in leftmost column on selecting/deselecting renditions).

Does not return descendants of the supplied element.

Please verify:

12: var elements = getDescendantsByTagName(document, '*')

should read

12: var elements = getDescendantsByTagName((el || document), '*')

Will need 3, 4, 5, 5.5, 6, 7, 8, 9 for now

I dont have an issue list / todo list in my fork so I am adding it here.

http://stackoverflow.com/questions/143847/best-way-to-find-an-item-in-a-javascript-array

Add it in file and update builder to use it

Howdy folks,

We could do with some sort of try / catch around the JSON.parse to handle empty JSON responses and badly formed JSON.

I am happy to implement, just want to discuss what the handled response should be.

"error": {
"status": 200,
"responseText": "Empty Response"
}

something like this??

With commonJS I could write code like

var delegate = require("jessie/functions/delegateQueryListener/rendition1.js")

delegate(someElem, "click", ".bar", function () {
    ...
})

There are two general ways to do this.

• Either make all your files commonJS compliant and use commonJS for the builder.
• Or have a seperate commonJS repo that auto generates commonJS compliant code from the builder.

I.e. either change the builder takes commonJS as input or change the builder to have multiple outputs, one of them being commonJS.

I'm open to doing the initial implementation once I have time.

See the line that assigns the result.

Need an option to exclude obfuscation as it is generally a bad (albeit really popular) idea. Doesn't make any sense unless you plan to develop and test with the obfuscated code, which is hardly ideal (though certainly doable).

As GZIP compression is commonly used, obfuscation adds little benefit anyway. Stripping out the comments and extraneous whitespace (should not a problem as we don't rely on ASI) is useful, though it should be done long before the code is released to QA (and ultimately to the end-users). Doing it on the eve of release will result in confusing error reports (line numbers won't match). Of course, there should not be any script errors at that point, right? :)

Would be useful for builder (e.g. reciprocal links between related functions).

In the latest pull request (#15) I have added a getEvent function to save the user typing "e || window.event". I am wondering if there is a better way?

I am trying to help the developer not write:

attachListener(el, "click", function(e){
e = e || window.event; // <-don't want to write this in every dom event handler
});

So with getEvent it would be:

attachListener(el, "click", function(e){
e = getEvent(e); // <- which I am not sure is nice or better either
});

Howdy All,

I have been thinking about how to document jessie and have an idea.

For each function, can we put a "More Info" link into the comments which points to wiki page.

In the specific the wiki page, we outline a each relies on can be a link to a wiki page.

If we make each pull dependant on an info wiki page, the doc's will slowly come together.

Thoughts?

Is it worth having a function for each of these, or are these already considered cross browser?

Need forked version of getViewportScrollPosition. Also have a naming incongruity with setScrollPosition.

Hi All,

As a user I would like to re-use the download url

When I use an existing url to populate the builder or cli, it may be out of date, ie. function names updated / moved.

Can we add a user notification in to inform them that features from the url are no longer available. Let the user deduce the reason, we just need to let them know that there is an issue.

You can use isOwnProperty from My Library to pull hasOwnProperty out of the mixin function. Will need two renditions of isOwnProperty, one with hasOwnProperty and one for browsers that don't support it (allegedly extinct, but we know where "pragmatism" gets us). :)

Should we keep these? What are their purpose?

b35d2b0#functions/delegateListener/rendition1.js

node_modules should be checked in, i.e. removed from the .gitignore, so that we can control the dependencies and make sure we have tested the builder with its dependencies. Otherwise we don't know which versions of the dependencies the builder is trying to work with and it may get an incompatible version of something and break the builder - which would be annoying for new comers

Wanted to start a discussion around testing, as I would like to start writing some tests for this so I have confidence when changing the code.

Where is it going to live? What framework (if any) is preferred?

I would like to use Jasmine, but not sure if this would work for testing a library?

This wrapping is oft-repeated and should likely go in the header/footer:

if (html) {

...

}

On that subject, I don't think browsers lacking document.documentElement are of any concern today; but, for completeness (and as many builds will be usable in such ancient browsers), we can use gEBTN (or document.all) to find it. That extra bit would likely go in an alternate header/footer. We'll need renditions of those, just like the functions. If want to support back to IE4 for some strange reason, will have to use the right header/footer. The builder can figure it out for them.

At the moment I'd just like to get that bit out of the function renditions.

I was just looking at the names of some of the functions and there is not an explicit naming convention; specifically for the functions pertaining to elements. For example, there is getHtml, addClass, getOuterSize which obviously are functions related to elements. But then there are others like; getElementTagName, getElementParentElement and getElementPositionStyles.

Ideally the first ones should be getElementHtml, addElementClass and getElementOuterSize or the others should be getTagName, getParentElement and getPositionStyles?

There are less that have 'Element' in them, so maybe rename these? Although I do like the idea of having 'Element' in the names of the functions so that it is clear they require elements to work. But I can also appreciate that it will make the function names longer - not sure if that is a problem or not. I prefer verbose names for functions as an obfuscation process can make them smaller if required.

Thoughts?

attachFocusDelegationListeners
center
centerInViewport
cloneObject
defer
getCssSize
getRectangle
getRectangleRelativeToDocument
getViewportRectangle
hasOverflow
hide
isAfterInDocument
isBeforeInDocument
isDescendantOfDocument
isInViewport
isPointerIn
isPointerInViewport
makeAdjacent
overlap
overlapViewport
playAudio
present
sendForm
serializeForm
setCssPosition
setCssSize
setInnerSize
setOuterSize
setPositionRelativeToDocument
setViewportScrollPosition
show
unpresent

Just set up the builder and wasn't expecting the various npm install calls that would be required. Easy enough, but needs instructions and/or a batch file (and equivalent shell script for *nix).

For example, forked rendition of 'bind' does not rely on Function.prototype.bind. Will use it (when available) to improve performance (so description should mention maximum performance, as well as maximum compatibility), but will work without it. On the contrary, rendition 1 has maximum performance, but relies on Function.prototype.bind to work.

I updated that one here and have been following that rule for newly added renditions (e.g. query), but haven't reviewed existing.

This won't make any difference to the builder at the moment. May never matter as rendition filters will not be based on individual methods. I think IE + JS degradation points will suffice for customized contexts.

Hi All,

Im looking at query rendition1 which appears to have a dependancy on querySelectorAll. Is this the case? if so, its not in the builder.

Thanks

Ian

Sending HTML response with text/javascript type.

Hi David,

What were you thinking for the signature of this function?

I was thinking xhrSend(url, options); where options would be {method: "post", timeoutSeconds: 30, complete: func, success: func, fail: func, ... }

Should xhrSend create a new xhr instance each time xhrSend is called or pass an instance in?

Adam

For context where element is absolutely positioned and without an offset parent, return offsetLeft/Top. Will be helpful for higher-level functions down the road (e.g. isElementInViewport).

It's a misnomer. How about deferUntilReady?

Should I add methods for these too? If so what names? getElementAttribute, setElementAttribute?

See positioning tip for design.

Currently this just does an xhr.send( data ), without making a check for a POST request. Also I think it should have some logic to convert data for a GET request to query string params? Or should this be an additional function/rendition?

When downloading jessie from the builder, it would be really great to have the url inc. query params injected into the header comments.

The builder should allow IE forks to be inside conditional comments. This currently includes the following:

If IE8 and below:
attachListener, getEventTarget, getEventTargetRelated, detachListener, attachWindowListener, detachWindowListener, cancelDefault, attachDocumentReadyListener

Note: Whilst IE7 can use XMLHttpRequest, there are some limitations i.e. local files dont' work so may have to let IE7 use ActiveXObject but probably just make a note of this limitation for now.

If IE6:
For IE6 we will need a conditional-comment rendition of sorts that iterates through different 'Msxml2.XMLHTTP.3.0' type thingies. So we don't need to split those out.

The conditional comment file will include the header1.inc and footer1.inc so there will be a very small amount of duplication going down the wire to IE.

Either with extra rows or pop ups; need to be able to look at code. Leaning towards extra rows that can be expanded/collapsed.

In the current changeset, I don't see any way to POST application/json (other than by interacting directly with the xhr returned from jessie.xhrCreate). e.g. ajaxPost and xhrPost do not seem to allow me to specify contentType which is hard-coded to application/x-www-form-urlencoded.

Is this by design, or should I allow these functions to set contentType based on what is specified in the options hash?

For example, there are several array-related function renditions that work only for contiguous arrays (perfect for query results, but inappropriate for sparse arrays). Am filling in those explanations as I work in that area.

There are others, for example, the 'mixin' rendition doesn't test for the legacy IE iteration bug. As a side note, we need a rendition that works, rather than degrades when that bug is present (requires a few more lines of code). We can have a version that skips the test (and forking), but the context must be explained (e.g. won't work if shadowing properties that exist on Object.prototype).

Another one is that the current query rendition is appropriate only for document contexts.

This is very important, not just for reliability, but to ensure that prospective users don't get hung up trying to spot "bugs" in the renditions. Most library users are used to functions that "fix" every known anomaly (which is a waste unless the application is designed to hit every pothole).

Hi Guys,

Just a thought, when we use the web builder we post a lot of key/value pairs with -1.

Would it be cleaner to omit these params and have the web builder / command.js default to -1 unless otherwise specified?

This makes the url injected into the comments must smaller and readable.

This has come from me dissecting the url in order to build a cli command.

TypeError: Cannot call method 'getDependencies' of undefined
at /Library/WebServer/Documents/projects/clones/jessie/builder/libs/jessie/Builder.js:232:24
at Array.forEach (native)
at sortDependencies (/Library/WebServer/Documents/projects/clones/jessie/builder/libs/jessie/Builder.js:230:15)
at jessie.Builder.build (/Library/WebServer/Documents/projects/clones/jessie/builder/libs/jessie/Builder.js:104:15)
at /Library/WebServer/Documents/projects/clones/jessie/builder/app.js:81:27
at callbacks (/Library/WebServer/Documents/projects/clones/jessie/builder/node_modules/express/lib/router/index.js:162:11)
at param (/Library/WebServer/Documents/projects/clones/jessie/builder/node_modules/express/lib/router/index.js:136:11)
at pass (/Library/WebServer/Documents/projects/clones/jessie/builder/node_modules/express/lib/router/index.js:143:5)
at Router._dispatch (/Library/WebServer/Documents/projects/clones/jessie/builder/node_modules/express/lib/router/index.js:170:5)
at Object.router (/Library/WebServer/Documents/projects/clones/jessie/builder/node_modules/express/lib/router/index.js:33:10)

When I jshint inherit I get the following error.

Linting js/lib/jessie.js...ERROR
Move the invocation into the parens that contain the function.
})();

This method is unique in its self invocation, should it be brought into line with the other functions?

Thinking of adding appendHtmlString to jessie, is it wanted/needed?

    function appendHtmlString(htmlString, element) {
        var docFragment = document.createElement('div'),
            child;

        docFragment.innerHTML = htmlString;

        while (child = docFragment.firstChild) {
            element.appendChild(child);
        }
    }

https://github.com/rassie/jessie/blob/master/functions/areFeatures/rendition1.js

Same as get/setPosition, but with extra argument to specify which corner (e.g. right/bottom instead of left/top). See Position Primer for example of getter. Setter will require measuring outer dimensions for all but left/top corner.