Protractor Chained vs Unchained SelectorsWhich characters are valid in CSS class names/selectors?Is there a CSS parent selector?What does the “+” (plus sign) CSS selector mean?Is there a “previous sibling” CSS selector?CSS selector for first element with classCSS '>' selector; what is it?Why do browsers match CSS selectors from right to left?Can I write a CSS selector selecting elements NOT having a certain class?What does the “~” (tilde/squiggle/twiddle) CSS selector mean?not:first-child selector
Language Selector
I had an c.p.a file late returns, stating i would get money. but i.r.s. says they were filed too late
Story about two rival crews terraforming a planet
What could a Medieval society do with excess animal blood?
Is よう an adjective or a noun?
Has there ever been a cold war other than between the U.S. and the U.S.S.R.?
What is the meaning of "stock" dilution on the Massive Dev Chart website?
What is the difference between figures illustration and images?
Should I cheat if the majority does it?
Why would a propellor have blades of different lengths?
How can solar sailed ships be protected from space debris?
Should I hide my travel history to the UK when I apply for an Australian visa?
CPLEX exceeds time limit issue
Does a reference have a storage location?
How frequently do Russian people still refer to others by their patronymic (отчество)?
Is there ever a reason not to use Java 8's parallelSort?
How to travel between two stationary worlds in the least amount of time? (time dilation)
List of Implementations for common OR problems
Sleepy tired vs physically tired
SQL Server error 242 with ANSI datetime
Upload csv into QGIS
Auto replacement of characters
Did Stalin kill all Soviet officers involved in the Winter War?
My mother co-signed for my car. Can she take it away from me if I am the one making car payments?
Protractor Chained vs Unchained Selectors
Which characters are valid in CSS class names/selectors?Is there a CSS parent selector?What does the “+” (plus sign) CSS selector mean?Is there a “previous sibling” CSS selector?CSS selector for first element with classCSS '>' selector; what is it?Why do browsers match CSS selectors from right to left?Can I write a CSS selector selecting elements NOT having a certain class?What does the “~” (tilde/squiggle/twiddle) CSS selector mean?not:first-child selector
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I think I understand that in Protractor,
$(selector1).$(selector2)
is generally equivalent to:
$(selector1 selector2)
Is there a reason to prefer one over the other, perhaps efficiency? My inclination is that the combined 2nd version is doing a single search, whereas the original version is doing multiple searches which sounds less efficient. However, when I read about how CSS actually performs, scanning the entire dom for each additional term in the expression (and doing it right-to-left starting with "key selector"), I wonder whether the code underneath Protractor makes it more efficient to first perform a simple selector to reduce the search space, depending on how the dotted ".$()" works when appended to a previous one.
And would the answer to this question change if comparing:
$$(multiCss).$(singleCss)
vs
$(multiCss singleCss)
And if there are no efficiency or correctness issues involved, is one form considered more readable than the other? This might be leaning into the area of opinion based answers, but I ask as a matter of whether one or the other is considered canonical style. If it's just a personal opinion and not a matter of canonical style, then forget this part of the question.
selenium-webdriver css-selectors protractor
add a comment |
I think I understand that in Protractor,
$(selector1).$(selector2)
is generally equivalent to:
$(selector1 selector2)
Is there a reason to prefer one over the other, perhaps efficiency? My inclination is that the combined 2nd version is doing a single search, whereas the original version is doing multiple searches which sounds less efficient. However, when I read about how CSS actually performs, scanning the entire dom for each additional term in the expression (and doing it right-to-left starting with "key selector"), I wonder whether the code underneath Protractor makes it more efficient to first perform a simple selector to reduce the search space, depending on how the dotted ".$()" works when appended to a previous one.
And would the answer to this question change if comparing:
$$(multiCss).$(singleCss)
vs
$(multiCss singleCss)
And if there are no efficiency or correctness issues involved, is one form considered more readable than the other? This might be leaning into the area of opinion based answers, but I ask as a matter of whether one or the other is considered canonical style. If it's just a personal opinion and not a matter of canonical style, then forget this part of the question.
selenium-webdriver css-selectors protractor
add a comment |
I think I understand that in Protractor,
$(selector1).$(selector2)
is generally equivalent to:
$(selector1 selector2)
Is there a reason to prefer one over the other, perhaps efficiency? My inclination is that the combined 2nd version is doing a single search, whereas the original version is doing multiple searches which sounds less efficient. However, when I read about how CSS actually performs, scanning the entire dom for each additional term in the expression (and doing it right-to-left starting with "key selector"), I wonder whether the code underneath Protractor makes it more efficient to first perform a simple selector to reduce the search space, depending on how the dotted ".$()" works when appended to a previous one.
And would the answer to this question change if comparing:
$$(multiCss).$(singleCss)
vs
$(multiCss singleCss)
And if there are no efficiency or correctness issues involved, is one form considered more readable than the other? This might be leaning into the area of opinion based answers, but I ask as a matter of whether one or the other is considered canonical style. If it's just a personal opinion and not a matter of canonical style, then forget this part of the question.
selenium-webdriver css-selectors protractor
I think I understand that in Protractor,
$(selector1).$(selector2)
is generally equivalent to:
$(selector1 selector2)
Is there a reason to prefer one over the other, perhaps efficiency? My inclination is that the combined 2nd version is doing a single search, whereas the original version is doing multiple searches which sounds less efficient. However, when I read about how CSS actually performs, scanning the entire dom for each additional term in the expression (and doing it right-to-left starting with "key selector"), I wonder whether the code underneath Protractor makes it more efficient to first perform a simple selector to reduce the search space, depending on how the dotted ".$()" works when appended to a previous one.
And would the answer to this question change if comparing:
$$(multiCss).$(singleCss)
vs
$(multiCss singleCss)
And if there are no efficiency or correctness issues involved, is one form considered more readable than the other? This might be leaning into the area of opinion based answers, but I ask as a matter of whether one or the other is considered canonical style. If it's just a personal opinion and not a matter of canonical style, then forget this part of the question.
selenium-webdriver css-selectors protractor
selenium-webdriver css-selectors protractor
edited Apr 16 at 19:18
Kevin Welker
asked Mar 25 at 16:09
Kevin WelkerKevin Welker
6,1581 gold badge26 silver badges52 bronze badges
6,1581 gold badge26 silver badges52 bronze badges
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I found this to be extremely interesting. Please note that this is NOT A CANONICAL ANSWER
This is only a collection of data from some tests that I ran regarding this subject. I will likely run further tests when I have a few hours to spare to properly setup a clean testing environment, but this is all I had time to do right now.
For my test, I was navigating to a page, then running an expect() on 10 separate elements to validate their text. This was locally hosted so internet speed did not play a factor. I ran the test 5 times with the elements selected like $().$()
, and then 5 more like $('CSS CSS')
. I then repeated the test in headless mode to see if I would get different results.
$().$() No Headless Times:
1) 16.062
2) 16.297
3) 15.029
4) 15.773
5) 16.699
Average: 15.972
$().$() Headless Times:
1) 14.705
2) 15.081
3) 15.806
4) 14.944
5) 14.997
Average: 15.107
$('CSS CSS') No Headless Times:
1) 16.172
2) 15.556
3) 16.604
4) 16.706
5) 15.733
Average: 16.154
$(CSS CSS) Headless Times:
1) 15.288
2) 15.136
3) 15.11
4) 15.152
5) 14.805
Average: 15.098
Like you, I expected $().$()
to be faster, and while this was true for non headless in my tests, not in any considerable way. Headless times ran basically the same speed regardless of how you did the selectors. The only useful take away from this data is that a potential difference in performance depending on selectors is small enough to not make noticeable difference, and would need to be tested on a much larger scale to possibly start seeing significantly different times. For sure something I want to look into more when I have enough free time to set up a properly large test case.
It might amplify your test to extend the chaining further than 1 element; i.e.,$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs$(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.
– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55342003%2fprotractor-chained-vs-unchained-selectors%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I found this to be extremely interesting. Please note that this is NOT A CANONICAL ANSWER
This is only a collection of data from some tests that I ran regarding this subject. I will likely run further tests when I have a few hours to spare to properly setup a clean testing environment, but this is all I had time to do right now.
For my test, I was navigating to a page, then running an expect() on 10 separate elements to validate their text. This was locally hosted so internet speed did not play a factor. I ran the test 5 times with the elements selected like $().$()
, and then 5 more like $('CSS CSS')
. I then repeated the test in headless mode to see if I would get different results.
$().$() No Headless Times:
1) 16.062
2) 16.297
3) 15.029
4) 15.773
5) 16.699
Average: 15.972
$().$() Headless Times:
1) 14.705
2) 15.081
3) 15.806
4) 14.944
5) 14.997
Average: 15.107
$('CSS CSS') No Headless Times:
1) 16.172
2) 15.556
3) 16.604
4) 16.706
5) 15.733
Average: 16.154
$(CSS CSS) Headless Times:
1) 15.288
2) 15.136
3) 15.11
4) 15.152
5) 14.805
Average: 15.098
Like you, I expected $().$()
to be faster, and while this was true for non headless in my tests, not in any considerable way. Headless times ran basically the same speed regardless of how you did the selectors. The only useful take away from this data is that a potential difference in performance depending on selectors is small enough to not make noticeable difference, and would need to be tested on a much larger scale to possibly start seeing significantly different times. For sure something I want to look into more when I have enough free time to set up a properly large test case.
It might amplify your test to extend the chaining further than 1 element; i.e.,$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs$(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.
– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
add a comment |
I found this to be extremely interesting. Please note that this is NOT A CANONICAL ANSWER
This is only a collection of data from some tests that I ran regarding this subject. I will likely run further tests when I have a few hours to spare to properly setup a clean testing environment, but this is all I had time to do right now.
For my test, I was navigating to a page, then running an expect() on 10 separate elements to validate their text. This was locally hosted so internet speed did not play a factor. I ran the test 5 times with the elements selected like $().$()
, and then 5 more like $('CSS CSS')
. I then repeated the test in headless mode to see if I would get different results.
$().$() No Headless Times:
1) 16.062
2) 16.297
3) 15.029
4) 15.773
5) 16.699
Average: 15.972
$().$() Headless Times:
1) 14.705
2) 15.081
3) 15.806
4) 14.944
5) 14.997
Average: 15.107
$('CSS CSS') No Headless Times:
1) 16.172
2) 15.556
3) 16.604
4) 16.706
5) 15.733
Average: 16.154
$(CSS CSS) Headless Times:
1) 15.288
2) 15.136
3) 15.11
4) 15.152
5) 14.805
Average: 15.098
Like you, I expected $().$()
to be faster, and while this was true for non headless in my tests, not in any considerable way. Headless times ran basically the same speed regardless of how you did the selectors. The only useful take away from this data is that a potential difference in performance depending on selectors is small enough to not make noticeable difference, and would need to be tested on a much larger scale to possibly start seeing significantly different times. For sure something I want to look into more when I have enough free time to set up a properly large test case.
It might amplify your test to extend the chaining further than 1 element; i.e.,$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs$(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.
– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
add a comment |
I found this to be extremely interesting. Please note that this is NOT A CANONICAL ANSWER
This is only a collection of data from some tests that I ran regarding this subject. I will likely run further tests when I have a few hours to spare to properly setup a clean testing environment, but this is all I had time to do right now.
For my test, I was navigating to a page, then running an expect() on 10 separate elements to validate their text. This was locally hosted so internet speed did not play a factor. I ran the test 5 times with the elements selected like $().$()
, and then 5 more like $('CSS CSS')
. I then repeated the test in headless mode to see if I would get different results.
$().$() No Headless Times:
1) 16.062
2) 16.297
3) 15.029
4) 15.773
5) 16.699
Average: 15.972
$().$() Headless Times:
1) 14.705
2) 15.081
3) 15.806
4) 14.944
5) 14.997
Average: 15.107
$('CSS CSS') No Headless Times:
1) 16.172
2) 15.556
3) 16.604
4) 16.706
5) 15.733
Average: 16.154
$(CSS CSS) Headless Times:
1) 15.288
2) 15.136
3) 15.11
4) 15.152
5) 14.805
Average: 15.098
Like you, I expected $().$()
to be faster, and while this was true for non headless in my tests, not in any considerable way. Headless times ran basically the same speed regardless of how you did the selectors. The only useful take away from this data is that a potential difference in performance depending on selectors is small enough to not make noticeable difference, and would need to be tested on a much larger scale to possibly start seeing significantly different times. For sure something I want to look into more when I have enough free time to set up a properly large test case.
I found this to be extremely interesting. Please note that this is NOT A CANONICAL ANSWER
This is only a collection of data from some tests that I ran regarding this subject. I will likely run further tests when I have a few hours to spare to properly setup a clean testing environment, but this is all I had time to do right now.
For my test, I was navigating to a page, then running an expect() on 10 separate elements to validate their text. This was locally hosted so internet speed did not play a factor. I ran the test 5 times with the elements selected like $().$()
, and then 5 more like $('CSS CSS')
. I then repeated the test in headless mode to see if I would get different results.
$().$() No Headless Times:
1) 16.062
2) 16.297
3) 15.029
4) 15.773
5) 16.699
Average: 15.972
$().$() Headless Times:
1) 14.705
2) 15.081
3) 15.806
4) 14.944
5) 14.997
Average: 15.107
$('CSS CSS') No Headless Times:
1) 16.172
2) 15.556
3) 16.604
4) 16.706
5) 15.733
Average: 16.154
$(CSS CSS) Headless Times:
1) 15.288
2) 15.136
3) 15.11
4) 15.152
5) 14.805
Average: 15.098
Like you, I expected $().$()
to be faster, and while this was true for non headless in my tests, not in any considerable way. Headless times ran basically the same speed regardless of how you did the selectors. The only useful take away from this data is that a potential difference in performance depending on selectors is small enough to not make noticeable difference, and would need to be tested on a much larger scale to possibly start seeing significantly different times. For sure something I want to look into more when I have enough free time to set up a properly large test case.
answered Mar 25 at 18:41
Ben MohorcBen Mohorc
5773 silver badges15 bronze badges
5773 silver badges15 bronze badges
It might amplify your test to extend the chaining further than 1 element; i.e.,$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs$(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.
– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
add a comment |
It might amplify your test to extend the chaining further than 1 element; i.e.,$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs$(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.
– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
It might amplify your test to extend the chaining further than 1 element; i.e.,
$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs $(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.– Kevin Welker
Mar 25 at 19:04
It might amplify your test to extend the chaining further than 1 element; i.e.,
$(css1).$(css2).$(css3).$(css4).$(css5).$(css6)
vs $(css1 css2 css3 css4 css5 css6)
. Results may also vary depending on the size and complexity of your web page. It wasn't clear whether your experiment was for a full fledged SPA web-app or a simple "Hello World" web page.– Kevin Welker
Mar 25 at 19:04
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
@KevinWelker Good idea. I was using a full SPA so it had a reasonable amount of complexity. At the same time, additional complexity of the app could bring in more unknowns as far as loading times so I am just using the landing page. I will 100% expand the test when I have time. The test suite I work on has thousands of element calls so even if the performance improvement is small, this could be a decent performance improvement overall for me
– Ben Mohorc
Mar 25 at 20:11
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
upvoting for effort and info (thanks), but not yet selecting, b/c as you said this is not canonical. So based on this small evidence, there's possibly no difference in efficiency, but are there some other reasons to prefer one over the other when both CSS expressions are static and could be easily combined into a single expression?
– Kevin Welker
Apr 11 at 15:57
add a comment |
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55342003%2fprotractor-chained-vs-unchained-selectors%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown