Provide parse functionality to aid in serialization

[ermik]

Description This is a feature request.

Steps to reproduce the issue:

1. Use quad.ToString(quad.IRI("val")) to create "<val>"
2. Attempt to parse it using methods provided in quad package

Received results: quad.MakeRaw which has been marked as deprecated, will produce correct results quad.MakeIRI suggested in deprecation notice will create an IRI of IRI <<val>> which is invalid.

Expected results: I expected to see a pair of methods clearly noted to be used from Marshalling and Unmarshaling quad.Value.

[ghostd]

@alexander-akait do you mean we should refactor the code to strictly follow the spec (and create structures like "Invert" and "Negate" in an intermediate step as defined in the spec, by wrapping the matching AST node)? Or "just" refactor the code to follow the spec as much as possible with our current AST nodes without intermediate transformation ?

[alexander-akait]

Or "just" refactor the code to follow the spec as much as possible with our current AST nodes without intermediate transformation ?

I am fine with it, too

But will be great if you try to, but we can postpone it:

@alexander-akait do you mean we should refactor the code to strictly follow the spec (and create structures like "Invert" and "Negate" in an intermediate step as defined in the spec, by wrapping the matching AST node)?

Not at the parser level, just like PoC (i know it can take a time), because it may turn out that it is faster and more convenient.

[ghostd]

@alexander-akait btw, i just read this from the spec:

It’s important to maintain zero-valued terms, so the calc() doesn’t suddenly "change shape" in the middle of a transition when one of the values happens to have a zero value temporarily.

Do you think it's relevant in our case?

[alexander-akait]

@ghostd And yes and no, look at example:

https://tomhodgins.com/demo/cssom/

and put the code:

.class {
    width: calc(20px + 0px);
}

.class {
    width: calc(20px + 0%);
}

you will see how it works

[ghostd]

Not at the parser level, just like PoC (i know it can take a time), because it may turn out that it is faster and more convenient.

Ok, i'll give a try (in an other poc-branch) to refactor our current implementation like this:

• swc parse the CSS string (no changes)
• visit_mut_component_value calls our "simplify calc" function (no changes)
• transform our calc AST into an intermediate "CSS operator trees" as defined by https://www.w3.org/TR/css-values-4/#parse-a-calculation
• actually simplify the intermediate tree by following the spec
• serialize the intermediate tree into the our common AST nodes (i guess unwrapping the structures will be enough)

Is that ok for you?

[ghostd]

you will see how it works

Thanks for the pointer.

So i understood the spec correctly, and this PR is wrong since it transforms width: calc(20px + 0%); into width: calc(20px);... which is wrong. The simplification of calc(20px + 0px) into calc(20px) is already merged.

[alexander-akait]

@ghostd Yes, that is ideal solution :star:

I think we need more 0 test here, with 0%, 0px, just 0, before/after parens and etc

[kdy1]

@ghostd Would you mind if I take on this?

[ghostd]

@kdy1 of course you can :)

I hope finish the other PR this weekend (i signed for a new position and was busy last weeks).

[kdy1]

Thank you!