Please people make the guy writing the WSF's life easier

[an-OK-squirrel]

And post your ideas for the WSF here. Some of the ideas going on here are going to be impossible to do, which sucks for me.

[an-OK-squirrel]

Also, view the current WSF here: https://github.com/ElementalCode/Elemental/wiki/WSF-Format

[robinp7720]

I'd recommend something like this to avoid cluttered block categories and because your forgetting the fact you can drag blocks and scripts:

http://scratchblocks.github.io/#html%20%3A%3A%20hat%20events%0A(header)%20Attributes%3A%20()%2B%20%3A%3A%20cstart%20control%0A%2F%2F%20stuff%0A%3A%3Acend%0A(body)%20Attributes%3A%20(%5Blang%20v%5D%3D%5Ben%5D)%20%2B%3A%3A%20cstart%20control%0A%2F%2F%20stuff%0A%3A%3Acend

[
    {
        scriptType: "html",
        position: {
            x: 100,
            y: 100
        },
        scriptContent: [
            {
                type: "c-container",
                data: {
                    values: {
                        tag: "header",
                        attr: {}
                    }
                },
                content: {

                }
            },
            {
                type: "c-container",
                data: {
                    values: {
                        tag: "body",
                        attr: {
                            "lang": "en"
                        }
                    }
                },
                content: {

                }
            }
        ]
    }
]

This would be much more expandable and flexible.
The final save file doesnt have to be human readable, just easy for a computer to understand

[matthewr6]

As long as you can compile the HTML and CSS blocks to this -
#4 (comment)
we should be good. No need to make our own json format.

[matthewr6]

#27

[an-OK-squirrel]

:/

[matthewr6]

Seemed basically the same.

[an-OK-squirrel]

I'll use something like robin's.

[matthewr6]

Could you at least check out and mess around with the npm links I gave? It'd be a lot easier to write compilers that way.

[an-OK-squirrel]

That's not block-based tho

[matthewr6]

Yeah, I mean compile the blocks into that JSON format

[robinp7720]

We can easly write out own parser.
If need be, I'll make it.
But my json format will allow multiple scripts and moving scripts and data values while keeping the original save state. Your method would require having a block for every thing tag and not supporting moving scripts and not even mutiple scripts

[an-OK-squirrel]

What I don't like it you have body and head as seperate blocks. You can't have more than one body, so there's no point!

[matthewr6]

I vote the npm packages and GH repo, but let's wait for some other people's input.
@an-OK-squirrel are you talking about my links or robin's suggestion?

[an-OK-squirrel]

robin's

[an-OK-squirrel]

I vote robin's

[robinp7720]

@Firedrake969 You'd be having to recompile the project every time when you load it and saving would loose you so much data.

@an-OK-squirrel my idea litterly has 2 blocks and the rest are data types such as attribute blocks and tag blocks.

having seperate blocks of head and body would over complicate things and make saving a little more complicated

[an-OK-squirrel]

What I'm saying is that I like head and body being combined into one block.

[matthewr6]

lose*
Any JSON-based saving requires recompiling based on the JSON, lol, not sure what you mean

also, for CSS -
https://github.com/aramk/CSSJSON

[quat1024]

http://scratchblocks.github.io/#html%20%3A%3A%20hat%20events%0Ahead%20%3A%3Acstart%20control%0A%20%20...%0Abody%20%3A%3Acelse%0A%20%20...%0A%3A%3Acend%20cap

[matthewr6]

btw PJ and I did talk about this earlier...
#4 (comment)

[an-OK-squirrel]

Yes, what quat said. Like that :P

[matthewr6]

Yeah, I know

[matthewr6]

http://prntscr.com/7wv270

[robinp7720]

If we we're to combine it, there would be multiple c blocks with and without the tag selectors and it would just be alot more complicated to save.

[an-OK-squirrel]

What?

[PullJosh]

Just realised this is still closed. :P

[robinp7720]

I still think that we should allow html tags inside of the c block as it would limit advanced users. There is no harm in doing so

[quat1024]

I still think that we should allow html tags inside of the c block as it would limit advanced users. There is no harm in doing so

Do you mean, like, typing in custom html tags?

If we have every html tag in the dropdown, we don't need to allow typing. But something like a dropdown that also lets you type in stuff into it yeah nice

[an-OK-squirrel]

Yeah, I'm going to go back to working now. Seeya :P

[an-OK-squirrel]

Basically what that means is that I'm not listening to any of the suggestions from now to when I finish it.

[PullJosh]

Which was why I closed this. (Looking at you, @quat1024. :3)

[PullJosh]

Just want to give everyone a quick heads-up: I updated the project goal in the readme to better explain what we're trying to do with Elemental. Please read it, and keep the goal in mind when making design decisions.

The goal of Elemental is to act as a bridge between Scratch and front-end web technology. Any and all design decisions will focus on teaching how to write clean, easy-to-read, valid front-end code. There should be as little opportunity for error as possible, thus bridging the syntax gap. Users of Elemental should not be expected to continue using Elemental once they become advanced users. Instead, they should be encouraged to convert to text-based code, for a quicker, more powerful, and more extensible coding experience.

[an-OK-squirrel]

Yes! Closing this and working now.

[matthewr6]

Robin, you're misunderstanding me and getting confused.
I keep saying that we already decided to have the zip with the actual HTML/CSS and then the json for the project editor. The library is NOT meant to convert the blocks - it's just for HTML/JSON parsing. What part do you not understand? :/ You're trying to say mostly what we've already said, making it seem like you haven't read through any of the previous issue at all, though I may be wrong.

You keep mentioning "your" format - what makes you think we're using it? We're just trying to persuade each other here xD

Anyways. Hope you guys all see what I'm getting at - purely the back-and-forth conversion of HTML/JSON so the user can open up their project in a browser after someone writes the block parser to the JSON format.

about age - I won't disclose my age, but you should be able to get a good idea if you've read my Scratch stuff before (About Me/What I'm Working On) and have seen my other accounts on the Internet.

[robinp7720]

@Firedrake969 Of course we would be using a zip to save the exported files.but we cant use it for what you want to use it. We need to save block positions within the project.

[matthewr6]

Not really given that there's only one overarching position per page, and that's the HTML/head/body one.
Of course you're saying that we're using a zip - we already decided!

[robinp7720]

@quat1024 No I was relating to another suggestion I made about categorized tag blocks/operators.
So instead of a hard to find tag inside of a list, we would be using the block category pane to sort tag blocks/operators.

[matthewr6]

Actually, know what we should do?
Drop this. Come back to it later once we get the actual blocks working, since that part is kind of important to the editor...

[robinp7720]

@Firedrake969 Yes for now we could do it your way but honestly, may way would support every way of creating a certain layout. Your way doesnt really care about the position of the blocks thus the saved project isn't the project you wanted to save.

While your method is easier for humans to read, my method is easier for compiling and viewing within the block editor.

[matthewr6]

There is only one position - where the head/body tag grouping is. Anything else is superfluous. It's like putting HTML tags before the DOCTYPE declaration or after the closing html tag.

Also, we can just add X and Y coordinates to the JSON object if we really really want the precise position. "My" and "your" methods have nothing to do with readability since humans should never need to see the JSON unless they're the developers, lol

anyways I'm going to lock this because I think it's a waste of time until we can actually get blocks working, and it'd be better for everyone to spend their time elswhere for now

[an-OK-squirrel]

guys, I closed the issue for a reason

[matthewr6]

I'm locking it too :P

[an-OK-squirrel]

I don't want a lock.

[matthewr6]

Leave it.

[an-OK-squirrel]

:/

[an-OK-squirrel]

Whatever, it's not a big deal. I just feel that it doesn't do anything since we're all collaborators.

[matthewr6]

It was mainly robin arguing with me, so I was just shutting it down.

[an-OK-squirrel]

kk, also check out #46

[PullJosh]

You mean to just your page, right?

We can add to all the other wiki pages, if need be?

[an-OK-squirrel]

Just to the the format page and block page.