Re: [css-gcpm] String-set issues

Brad Kemper wrote:

 >  1. 'string-set' is a weird and confusing property name. It sounds
 >  like it is for a set of something, but I think really 'set' is
 >  meant to mean that you are assigning a (string) value to a name.
 >  We don't do that in other places where we have named things. For
 >  instance, we have '@counter-style', not '@counter-style-set';
 >  '--foo', not 'foo-set', the 'font-family' descriptor of
 >  @font-face, not 'font-family-set', etc.

I like 'string-set'. It uses 'set' similar to 'reset' (as in
'counter-reset'). The property is interoperably implemented by
Prince/AntennaHouse, so it would take some convincing to make the
change.

 >  2. Pseudo-elements are excluded from being able to use
 >  'string-set', so the 'content()' function has its own way of
 >  accessing them. That seems unnecessary. Just let pseudo-elements
 >  assign their contents to a named string, if you need that. It is
 >  simpler to learn, and less complicated, because you just use
 >  selectors like you normally do with pseudos. And really, most of
 >  the time, you won't even need that, because the actual element has
 >  access to the counter too, and that can be assigned to a name
 >  there. This would also eliminate the need for parentheses after
 >  the keyword 'content'.

This could work, too. There would be more declarations, which some
would consider more complex, but the values would -- like you say --
be simpler. Again, the question will be whether implementors are
prepared to make changes that doesn't add new functionality.

 >  3. 'string-set' only gets the text of the element. I would think
 >  there are times when it would be useful to get all the content
 >  nodes, including links, bolds, small pictures, spans with class
 >  names, etc.

Yes, this is what running elements are for.

   https://books.spec.whatwg.org/#running-elements

 >  4. When 'string()' is used to access a named string, it ignores
 >  what was set on assigned to that name for elements not on the
 >  page. 

I'm not following you here. By default, named strings carries the
values from one page to the next (unless set to some other value).

 >  But in CSS3-content [2], the examples include 'META[author]
 >  { string-set: author attr(author); }', which selects something
 >  completely outside the page and uses it. Is this because the two
 >  drafts are out-of0synch, or are all these examples supposed to
 >  work somehow?

The example works as expected -- the META elemet sets the "author"
string which can be referred to later in the document. This is e.g.
used when listing the author's name in a running header.

 >  5. Normally when we assign a value to some sort of name in CSS, it
 >  is one value that is globally available. But with named stings in
 >  this draft, every name has multiple values (one for each
 >  selector-matched element within each page, multiplied by the
 >  number of pages, since the name only has page-wide scope in all
 >  the examples of this draft), so that the string() function can
 >  access right element, based on its position on the page. For
 >  instance, with 'string(theName, first)', the "value of the first
 >  assignment on the page is used". Meaning, I think, that if the
 >  element is the first occurrence of those on the page that match
 >  the selector, then it uses that element for the value assigned to
 >  that name. I think it would be better to just use selectors and
 >  pseudo-classes to select the right element, rather than to have
 >  that take place within the function inside the property value.

How would you use selectors to express these use cases:

   In this example, the first term on the page will be shown in the
   top left corner and the last term on the page will be shown in the
   top right corner. In top center of the page, the first letter of
   first term will be shown.

     @page { @top-left { content: string(term, first) }}
     @page { @top-right { content: string(term, last) }}
     @page { @top-center { content: string(index, first) }}
     dt { string-set: index content(first-letter), term content(text) }

   https://books.spec.whatwg.org/#using-named-strings

 >  6. In the 'string()' function, the 'start' keyword is not well
 >  defined. It says "If the element is the first element on the
 >  page". Is that by document order? What if it has a parent?
 >  Technically, doesn't the parent come first? Also, I didn't really
 >  get what 'first-except' was for.

The description is slightly revised here:

     ''start'': the value of the first assignment on the page is used
     if the element begins the page or the named string has not been
     assigned a value. Otherwise, the named string's entry value is
     used.

   https://books.spec.whatwg.org/#using-named-strings

 >  7. In the 'string-set', <content-list> can be used to construct a
 >  string from the text contents of the element (using 'content()'),
 >  as well as from literal text, counters, and attributes, and assign
 >  it to a name. But then, when you want to use a string like that,
 >  there is the 'string()' function. With that, you get that named
 >  string and construct a string from it and from literal text,
 >  counters, and attributes, and assign it to the 'content'
 >  attribute. This seems unnecessarily redundant, which can make it
 >  confusing. Since 'content' can already string together text from
 >  multiple sources, we don't really need to do it before assigning
 >  it to a name too, do we? If we need multiple things from the
 >  original element (its text and one of its attributes and its
 >  counter, for instance), they can just be each assigned to
 >  individual names, which can then be pulled into 'content' to be
 >  strung together. I think it is more author-friendly to just give
 >  us one place to concatenate strings together for the content, and
 >  let other properties and functions do their own things. Separation
 >  of concerns.

You're right that the thing can be expressed in two slightly different
ways. Somewhat like shorthand and longhand syntax. I don't see it as a
problem; it has been interoperably implemented, and it allows authors
to express the stringing together where they think is best.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Monday, 24 November 2014 18:50:22 UTC