-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse simple expressions #389
base: main
Are you sure you want to change the base?
Conversation
public function functionArithmeticInFile() | ||
{ | ||
$oDoc = self::parsedStructureForFile('function-arithmetic', Settings::create()->withMultibyteSupport(true)); | ||
$sExpected = 'div {height: max(300,vh + 10);} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, vh without a number in front is still not valid and I’d prefer it would throw an error in strict mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, it is invalid, however this seems to be outside of the scope of these changes. I guess we need a separate issue for this. Also is it a concern of the parser to validate the semantic meaning of identifiers it encounters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also is it a concern of the parser to validate the semantic meaning of identifiers it encounters?
I agree it's not.
Moving forwards, we've agreed to replace strict mode parsing with a logging mechanism. And try to replicate what most browsers do when encountering invalid syntax. A unit with no number in front should therefore probably be parsed as zero of that unit. And, as a bonus, a separate PR would log the lack of a number.
So, for now, we don't need to worry about strict mode, but should create issues for things that could be logged in future.
For what it's worth, I'm including this patch in ampproject/amp-wp#7487 and it is passing all tests in our project. |
@oliverklee was this closed as well as other PRs (e.g. #185 and #193) just because the |
@westonruter Oh no! It indeed was. ;-( |
I have now reinstated the legacy |
I would prefer we delete the |
@sabberworm Oh, I wasn't aware that this was possible in the first place! Will do. |
I have now moved all PRs over to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. I'd be happy for this to be merged. @oliverklee, @sabberworm WDYT?
public function functionArithmeticInFile() | ||
{ | ||
$oDoc = self::parsedStructureForFile('function-arithmetic', Settings::create()->withMultibyteSupport(true)); | ||
$sExpected = 'div {height: max(300,vh + 10);} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also is it a concern of the parser to validate the semantic meaning of identifiers it encounters?
I agree it's not.
Moving forwards, we've agreed to replace strict mode parsing with a logging mechanism. And try to replicate what most browsers do when encountering invalid syntax. A unit with no number in front should therefore probably be parsed as zero of that unit. And, as a bonus, a separate PR would log the lack of a number.
So, for now, we don't need to worry about strict mode, but should create issues for things that could be logged in future.
src/Value/CSSFunction.php
Outdated
/** | ||
* @param ParserState $oParserState | ||
* @param bool $bIgnoreCase | ||
* | ||
* @return string | ||
* | ||
* @throws SourceException | ||
* @throws UnexpectedEOFException | ||
* @throws UnexpectedTokenException | ||
*/ | ||
public static function parseName(ParserState $oParserState, $bIgnoreCase = false) | ||
{ | ||
return $oParserState->parseIdentifier($bIgnoreCase); | ||
} | ||
|
||
/** | ||
* @param ParserState $oParserState | ||
* | ||
* @return array | ||
* | ||
* @throws SourceException | ||
* @throws UnexpectedEOFException | ||
* @throws UnexpectedTokenException | ||
*/ | ||
public static function parseArgs(ParserState $oParserState) | ||
{ | ||
return Value::parseValue($oParserState, ['=', ' ', ',']); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice refactoring. Could this be put through as a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a changelog entry, though.
src/Value/Expression.php
Outdated
<?php | ||
|
||
namespace Sabberworm\CSS\Value; | ||
|
||
use Sabberworm\CSS\OutputFormat; | ||
use Sabberworm\CSS\Parsing\ParserState; | ||
|
||
/** | ||
* An `Expression` represents a special kind of value that is comprised of multiple components wrapped in parenthesis. | ||
* Examle `height: (vh - 10);`. | ||
*/ | ||
class Expression extends CSSFunction | ||
{ | ||
/** | ||
* @param ParserState $oParserState | ||
* @param bool $bIgnoreCase | ||
* | ||
* @return Expression | ||
* | ||
* @throws SourceException | ||
* @throws UnexpectedEOFException | ||
* @throws UnexpectedTokenException | ||
*/ | ||
public static function parse(ParserState $oParserState, $bIgnoreCase = false) | ||
{ | ||
$oParserState->consume('('); | ||
$aArguments = self::parseArgs($oParserState); | ||
$mResult = new Expression("", $aArguments, ',', $oParserState->currentLine()); | ||
$oParserState->consume(')'); | ||
return $mResult; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a class-specific unit test for this new class. The overall parser tests are good, but we also want to make sure each individual class behaves as it should.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raxbg, would you be willing to create a corresponding TestExpression
class to test this new class as a standalone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a class-specific unit test for this new class. The overall parser tests are good, but we also want to make sure each individual class behaves as it should.
Makes sense. How does that look like: 14118a2
On further looking, a class-specific unit test is also needed for the new class (inherited from the terribly misnomered |
Also, according to the original commit message, this builds on on top of #390. So we should get that in first and then rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get #390 in first.
#390 is closed now and seems like it's no longer needed. There shouldn't be anything else blocking the merge of this PR :) Let me know if you have any concerns |
Fixes #388
Builds on top of #390