No newline here

Maybe add newlines between the lambda definitions

If we are parsing the value ourselves, I don't know if this would do anything. I think it also gives the wrong impression that these are the values that position-area accepts, while the reality is more complicated.

It mostly lists them on webkit.org/css-status , but nothing else really.

(Also none is missing from this list)

I'm fine either way regarding keeping this list.

no need for const, here and below.

same here

We should never get here, right? So this should also be ASSERT_NOT_REACHED();

A few comments...

First, it's not a good idea to name things after numerical indexes into the spec. The spec can get rearranged for editorial reasons, and it doesn't explain what the underlying logic is. The question you have to ask yourself is, why are are the branches oriented that way? I promise you there's good reasons. :) That logic is what you should use to organize your code.

Second, the grammar in the spec is written that way for understandability. It's not necessarily the best organization for implementing. In this case, if you consume the first ident, and it is not either center or span-all, then you can identify its axis as well as whether it should be first or second in canonical order. You can plug that into your output pair. With that information, you can know what kind of keyword is valid for the second axis, and validate and store it accordingly as well. If instead you fell through into the center or span-all case, then you store this value while you parse the second keyword, and then you can plug both into your output pair once you've identified the axis of the second keyword.

You can do this with switch/case, and it will not only be easier to understand, it'll also be faster than 50+ conditional branches (which is what || produces).

This structure is about the computed value, not the specified value, right? So here you should think about how you intend to use the value, and encapsulate that logic accordingly. The users of this object don't care about the keywords. They are going to want to pass in some WritingMode information and get back out the used value in their own coordinate space. And they're going to want to get this information efficiently.

So think about abstracting the information in this class. What do the keywords really mean? Instead of maintaining a collection of keywords, you could, for example break this down into:

• Which of the start/center/end tracks are selected? (3 bits per axis)
• Am I interpreting the axis as a) physical coordinates b) container x/y logical coordinates c) self x/y logical coordinates d) container block/inline logical coordinates or e) self block/inline logical coordinates (3 bits per axis)

If you organize your values internally like this, then it'll be much easier to add on helper functions that rapidly return used values.

And also, if your parsing function is reliably returning the x or block value first, and the y or inline value second (which it should, because we should only be doing validation in one place, not two), then you can easily assign the parsed values into the computed value structure using switch/case.