Koji Ishii | 23 Nov 17:56 2014
Picon

[css-text] What else is needed to be defined for text-justify: auto?

I read the IRC log of discussions at TPAC[1], saying:

> RESOLVED: No examples of justification algo for text-justify: auto, link to a wiki or note desc language
specific conventions

It’s great to have resolved this, thank you all for the effort.

However, it’s still a bit unclear what else needed in the spec.

Was that the consensus that "text-justify: auto" is completely UA dependent and doesn’t define any
testable definitions? All this discussions started seeking for more testable definitions, and the
resolution does not clarify if we don’t pursue that further, or just decided not to do one.

[1] http://log.csswg.org/irc.w3.org/css/2014-10-28/#e487701

/koji

Mats Palmgren | 23 Nov 00:49 2014

[css-ui] text-overflow in overflow:visible blocks

'text-overflow' was recently changed to be applied at the line box edge
instead of the block's content edge.  Here's the relevant spec text:

"This property specifies rendering when inline content overflows its
line box edge in the inline progression direction of its block container
element ("the block") that has overflow other than visible."
http://dev.w3.org/csswg/css-ui/#text-overflow

I think we should take one step further and drop the "that has overflow
other than visible" requirement.

That was part of Tantek's proposal under "In addition, ..." here:
http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html

Was that part considered but rejected? (if so, why?) or is it simply
an oversight when updating the spec?

Regards,
Mats

Brad Kemper | 22 Nov 19:18 2014
Picon

[css-gcpm] String-set issues

I've been giving some attention named strings in the latest GCPM draft [1]. I have some issues and comments. I'll start with the things I think are problems, and then I'll propose how I'd like to see it improve.

Problems:

 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 ' <at> counter-style', not  ' <at> counter-style-set'; '--foo', not 'foo-set', the 'font-family' descriptor of <at> font-face, not 'font-family-set', etc.

 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'.

 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.

 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. 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?

 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.

 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.

 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.

Regarding the first point above, I think in some ways, 'string-set' is similar to 'flow-into', especially if we axe the concatenation stuff of #7 above. They both use the similar 'content' or 'contents' keywords to create a variable-like name to hold the original contents of the element. I think we can play off that, using that as mental equity for changing the name and syntax of 'string-set'. So, instead of 'string-set', I propose the following:

Name:   copy-into
Value:  none |  [ [ <custom-ident>  <content-level>] [,  <custom-ident>  <content-level>]*  ]?
Initial:        none
Applies to:     All elements, but not ::first-line or ::first-letter.
Inherited:      no

The 'copy-into' property contains one or more pairs, each consisting of an custom identifier (the name of the named string) followed by a content-level keyword describing how to construct the value of the named string.

<ident> = The element or its contents, or its text, or the value of a specified attribute or counter is copied and placed into an non-rendered content fragment with the name '<ident>'. The values none, inherit, default, auto and initial are invalid content fragment names.

<content-level> expands to one of the following values: 
element|contents|text|attr(<identifier>)|<counters>

element
the entire element is copied into the named content fragment (i'm using 'named content fragment' to mean the same thing as a named flow, but not intended to be flowed through multiple elements). 

contents
only the element’s contents are copied into the named content fragment. This is the default if <content-level> is not specified.

text
only the element’s text (including normally collapsed white space) is copied into the named content fragment.

attr(<identifier>)
the string value of the attribute <identifier> is copied into the named content fragment

<counters>
the value of a counter() function, as described in [CSS21] is copied into the named content fragment.
-----------------------------

So basically, it is the same as "flow-into", except that it does not remove anything, just a copy, and it has some other choices besides just "content" and "element" (I would also change "content" to "contents" in Regions). Plus, it can list several different names to copy stuff into, e.g. like this: 'copy-into: myContents contents, chapNum counter(chapter)'. And it has 'contents' as the default if one of the other levels is not specified instead.

By default, the content fragment name would be global, as the named flow is with 'flow-into'. But if one of the following pseudo-classes are used on the subject of the selector, then the name is locally scoped to just the page the element is on.

:nth-of-page(n)    The element is the nth matched element on the page.
:first-of-page       Same as :nth-of-page(n), but where n = 1 (it is the first matched element on the page).
:last-of-page       The element is the last matched element on the page.
:start-of-page      The element is the first matched element on the page, and neither it nor its ancestors have any previous siblings that appear on the page.

The content property would be able to accept the named content fragment as one of its value parts, just by using the identifier. It would not be part of a region chain, unless the whole element containing the named content fragment had "flow-into" something else.

So, for instance, here are Examples 1-3 of GCPM, re-written with this syntax:
--------
HTML:
<h1>Loomings on the <b>Horizon</b></h1>


CSS:
h1::before { content: 'Chapter ' counter(chapterNumber); }
h1:first-of-page { copy-into: headerP1 counter(chapter),
                                              headerP2; }
h1::after { content: '.' copy-into: headerP3; }
<at> top-center {
  content: headerP1 ": " headerP2 headerP3;
}

The value of the named string “headerP1” will be “Chapter 1", and the value of the named string “headerP2” will be "Loomings”. headerP2 will include the bold tags around "Horizon", because the <content-type> defaults to 'contents', not 'text'. The value of the named string “headerP3” will be ".”. The top-center content will be "Chapter 1: Loomings on the <b>Horizon</b>."

---------
HTML:
<section title="Loomings">

CSS:
section:first-of-page { copy-into: header attr(title) }

The value of the “header” string will be “Loomings”, assuming that section intersected with the page.

-----------
CSS:

<at> page {
  size: 15cm 10cm;
  margin: 1.5cm;

   <at> top-left {
     content: "first: " heading1;
  }
   <at> top-center {
     content: "start: " heading2;
  }
   <at> top-right {
     content: "last: " heading3;
  }

   <at> bottom-center {
     content: "start: " author;
  }
}

h2:first-of-page { copy-into: heading1 }
h2:start-of-page { copy-into: heading2 }
h2:last-of-page { copy-into: heading3 }
META[author] { copy-into: author attr(author); }

The rendered examples would be the same as in the spec, except that the author's name would appear at the bottom center of each page too.


Brad Kemper


1) http://www.w3.org/TR/css3-gcpm/
2) http://www.w3.org/TR/css3-content/#strings
Boris Zbarsky | 21 Nov 16:41 2014
Picon

[css-transforms] Transform functions should accept percentages

For example, http://dev.w3.org/csswg/css-transforms/#funcdef-translatey 
says:

   translateY() = translateY( <length> )

But in implementations, translateY accepts a length or a percentage.

-Boris

Sergio Villar Senin | 21 Nov 12:32 2014

[css-grid] Interactions between min/max-content and min/max-width

In section 10.5 of the specs, the "Grow All Tracks To Their Max" step
literally says:

"For the purpose of this step: if sizing the grid container under a
max-content constraint, the free space is infinite; if sizing under a
min-content constraint, the free space is zero."

If I am not wrong that's not always accurate, I'm thinking in two cases
in particular:

- grid container sized under max-content with a "definite" max-size.
Instead of infinity I guess we should respect the max-size.
- grid container sized under min-content with a "definite" min-size. In
this case instead of non distributing anything, I guess we should try to
fulfill the min-size restriction.

Are those assumptions correct?

BR

PS: I'm not sure if "definite" applies also to min/max-size, but I'm
using it in the sense of definite length.

Xidorn Quan | 21 Nov 06:49 2014
Picon

[css-ruby] Style of intra-annotation white spaces

I notice a problem when I implement the vertical positioning of ruby annotations. The problem is that, the intra-annotation white spaces cannot be properly styled, which makes the height of text container look incorrect. For example, there is a piece of code in the spec:

<ruby>
  <rb>one</rb> <rb>two</rb>
  <rt>1</rt> <rt>2</rt>
</ruby>

After generating anonymous boxes, the frame tree is similar to:

<ruby>
  <pseudo-rbc><rb>one</rb><pseudo-rb> <pseudo-rb><rb>two</rb></pseudo-rbc>
  <pseudo-rtc><rt>1</rt><pseudo-rt> </pseudo-rt><rt>2</rt></psedudo-rtc>
</ruby>

Here, authors cannot specify any style for the <pseudo-rt/>. It won't have a problem in normal case if UA gives the elements a proper default style. But in some cases, author may want to specify different style to annotations, for example, "rt { font-size: 30%; }". Then the boxes for the intra-annotation white space would be taller than its neighbors.

This problem is relatively less troublesome for <pseudo-rb/>s since authors can always specify styles to their parents, and let them inherit. But if an auithor changes the font-size of <rb>, he/she would notice this problem as well.

I have no idea about any perfect solution. But I suggest that we can make anonymous intra-annotation white spaces completely collapsed to nothing, and leave only the anonymous boxes for pairing.

- Xidorn
Brad Kemper | 21 Nov 05:27 2014
Picon

[css-regions]

In section 3.2.1 of CSS Regions [1], it says you can't have a element create a flow and also consume the same flow, and it gives this example:
#id { flow-into: foolish; flow-from: foolish; }

would move the #id element to a "foolish" named flow, and try to make the #id element a CSS Region for the "foolish" named flow. The "foolish" named flow would then contain its own region, creating a cycle. So the #id element does not become a CSS Region.

However, I think that restriction should only be the case when the keyword "contents" is not in the 'flow-from'. It doesn't say that anywhere that I could find, but it would be useful to do something like this:

#id { flow-into: significant  content; flow-from:significant; }
.some-empty-things {flow-from:significant;}
That way, the element matching #id could have a large amount of content in the natural markup, but it's height could be limited so that it flowed through the original container AND the additional regions. There would be no problem with a cycle to break. 

Brad Kemper

Christian Biesinger | 21 Nov 03:41 2014
Picon

Baseline of <select> elements

Hi there,

this may or may not be appropriate for this mailing list, but since I'm starting out with a CSS question I'll start here.

"The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge."

Now, a <select> element behaves a lot like an inline-block element, and UA default stylesheets make it one, though I guess it's technically a replaced element. Still, my question here is, what should be the baseline for a <select> that has a style of overflow: hidden as seen on http://panasonic.asia/in/airconditioner/EnergySavingCalculator.html (the select next to SELECT YOUR HOME TYPE)

Simplified testcase at http://jsbin.com/qosewufema/1/

IE and Firefox calculate the baseline ignoring the overflow: hidden. Blink currently notices the overflow: hidden and calculates the baseline as the bottom of the margin edge. Who is right?

-christian
Dael Jackson | 21 Nov 00:01 2014
Picon

[CSSWG] Minutes Telecon 2014-11-19

Re-naming flex-basis: auto
---------------------------

  - RESOLVED: Accept fantasai's proposal for flex-basis: auto changes
      (auto means main-size and add a keyword for automatic sizing)

Unicode-range syntax
---------------------

  - It was quickly agreed that the text could move to the Fonts spec.
  - There was disagreement between jdaggett and TabAtkins as to if
      this additional normative text was necessary for the spec,
      however, implementors stated that they did want the text
      available to them. A compromise was reached where it would be
      in an appendix so that regular authors wouldn't normally
      encounter it.
  - RESOLVED: Move the <urange> definition to an appendix in the
      Fonts spec.

CSS3-UI
-------

  - RESOLVED: Drop pseudo classes from CSS3-UI in favor of
      Selectors 4
  - RESOLVED: For clarity, all future pseudo-classes should be in a
      Selectors module
  - RESOLVED: Drop XFORMS related pseudo-elements.
  - A tracking of the moved and removed pseudo-elements and pseudo-
      classes is available here:
      https://wiki.csswg.org/spec/css4-ui#more-selectors
  - RESOLVED: Drop content: icon and the icon property
  - RESOLVED: pull nav-index from level 3 and put it on a wiki
  - Tantek requested that individuals add the URLs for discussions
      related to nav-index here:
      https://wiki.csswg.org/spec/css3-ui?&#issue-25
  - There wasn't time to discuss the text-overflow issue, so
      discussion will continue on the mailing list.

Box-Tree API
------------

  - RESOLVED: Create a taskforce to work on box-tree API and
      extensible CSS APIs

===== FULL MINUTES BELOW ======

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  John Daggett
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Mike Miller
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Adenilson Cavalcanti
  Bruno de Oliveira Abinader
  Dirk Schulze
  Mike Sherov
  Ian Vollick
  Lea Verou

  Scribe: dael

  plinss: Let's get started. Anything to add to the agenda?
  Florian: TabAtkins raised something about :has-focus. I'd like it
           added.
  plinss: Okay. No problem.

Re-naming flex-basis: auto
---------------------------

  <smfr> http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html
  plinss: Who wants to talk on this one?
  * fantasai proposes rossen lead
  TabAtkins: It's fantasai that wants to talk and she's not here yet.
             I'm not ready to talk on this yet.
  dael: [reads fantasai IRC comment]

  Rossen: I wasn't ready to talk either, but since it's there let's
          talk.
  plinss: We can defer.
  Rossen: I still haven't seen a mass response from developers on
          this. I did see leaverou say a week or so ago that she
          chatted with fantasai and gave her feedback.
  Rossen: That's just one sample.
  Rossen: If at all possible I'll keep pushing to change to the
          first option rather than the second which breaks
          compatibility and I believe is more confusing. That was
          the issue.
  Rossen: Where are we, like I said, I'm still waiting on feedback
          on it. If someone wants to add something we can discuss,
          otherwise we can defer.

  fantasai: I think leaverou's feedback was why not content size. I
            asked other implementors and they posted these:
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0040.html
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0041.html
  <fantasai> third author -
http://lists.w3.org/Archives/Public/www-style/2014Nov/0055.html
  fantasai: Someone else posted...let me find that.
  fantasai: A little bug seems like...it seems like it doesn't
            change backwards compatibility. The Mozilla bug was
            leaning toward not changing to main-size.
  dbaron: We've had the change that's been in the spec in nightly,
          but we pulled from beta given the set of regressions it
          caused. There's a decent compatibility risk, we've had
          things show up.
  dbaron: At this point my memory is a bit muddled between which
          changes caused what regressions.

  fantasai: What I've heard is Microsoft and Mozilla are worried
            about compatibility. Author side liked the other option,
            they don't like dealing with backwards compatibility
            problems and content as a keyword makes more sense.
            We're used to 'auto' computing to something. That's the
            feedback from dev I've pinged, I haven't heard feedback
            supporting the first.
  fantasai: Given that, I'd propose where auto means main-size and
            add a keyword saying 'I want automatic sizing' with
            content or content-size as the keyword.

  plinss: So we have a proposal. Opinions?
  TabAtkins: I like this less, but I won't fight it. It's fine.
  plinss: dbaron?
  dbaron: I'm fine with...I'm not into the issue that much, but if
          people think it's less of a backwards compatibility issue,
          I'm in favor.
  fantasai: It definitely will. It doesn't change meaning, just
            creates new syntax for something you previously couldn't
            access directly.
  plinss: Objections?
  Rossen: I don't want to break backwards compatibility.

  RESOLVED: Accept fantasai proposal for flex-basis: auto changes
            (auto means main-size and add a keyword for automatic
            sizing)

Unicode-range syntax
---------------------

  <jdaggett> basic problem, CSS 2.1 defined UNICODE-RANGE token
  <jdaggett> 2.1 tokenization:
http://www.w3.org/TR/CSS21/syndata.html#tokenization
  <jdaggett> UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
  <jdaggett> unicode-range descriptor of  <at> font-face rule uses this
  <jdaggett> sometimes interferes with other syntax in places
             outside  <at> font-face rules
  <jdaggett> like selectors: u+a { color: green } will get tossed by
             the parser

  jdaggett: The basic problem is in CSS2.1 the unicode-range token
            was defined. I put in the tokenization syntax above.
  jdaggett: The descriptor exists. The problem is sometimes this
            interferes with other grammar like selectors.
  jdaggett: I put a test case with the problem (below). It fails in
            Chrome and Firefox.
  <jdaggett> testcase:
http://people.mozilla.org/~jdaggett/unicoderangetokenization.html
  jdaggett: The basic resolution was to dump the unicode-range token
            and replace with something like An+B syntax.

  <jdaggett> telcon discussion in july:
             http://lists.w3.org/Archives/Public/www-style/2014Jul/0051.html
  <jdaggett> The resolution was to dump UNICODE-RANGE token, replace
             with production "something like An+B"
  <jdaggett> quick review unicode-range descriptor syntax
  <jdaggett> list of comma-delimited <urange> values
  <jdaggett> ex: unicode-range: u+f2e, u+100-1f3, u+2??
  <jdaggett> three basic types - single codepoint, range, wildcard
  <jdaggett> defined in CSS3 Fonts:
             http://dev.w3.org/csswg/css-fonts/#urange-value
  <jdaggett> TabAtkins wants to define <urange> in Syntax:
             dev.w3.org/csswg/css-syntax/#urange-syntax
  <jdaggett> seems like a verbose explanation of the same thing

  jdaggett: Basically there's 3 types. There's single codepoint,
            range, and wildcard. It's currently defined in CSS3
            Fonts, but TabAtkins wants to define the <urange>
            production in syntax spec. I put in the URL to existing
            and proposed above

  <jdaggett> and the grammar simply lists a bunch of possible token
             sequences
  <jdaggett> <urange> =
  <jdaggett> u '+' <ident-token> '?'* |
  <jdaggett> u <dimension-token> '?'* |
  <jdaggett> u <number-token> '?'* |
  <jdaggett> u <number-token> <dimension-token> |
  <jdaggett> u <number-token> <number-token> |
  <jdaggett> u '+' '?'+
  <jdaggett> but the algorithm is simply saying "take this jumble of
             tokens and reinterpret them as a sequence of..."
  <jdaggett> ends up being different (and incorrect) version of
             existing definition
  <jdaggett> and it's totally out of context since the Fonts spec
             explains what these ranges represent
  <jdaggett> and how they are used

  jdaggett: In the new description you have something like this
            (above)
  jdaggett: It ends up being different and not entirely correct. I
            think it's out of place too since you need information
            from Font spec, too. It's also just not in the spec
            where this thing is described how it's used.
  jdaggett: Resolving to remove the unicode-range token is fine, but
            this new syntax and algorithm doesn't make a lot of
            sense to me. It's really hard to read and implementors
            have to look at both Syntax and Font specs to use it
            correctly. Since it's only used for the unicode-range
            descriptor, we don't need it spread across specs.
  jdaggett: I'd suggest, in the process of removing the
            unicode-range token, we redefine <urange> to link to
            this and avoid linking to syntax spec.
  * fantasai thought we already removed the token?
  <ChrisL> agree it makes sense for all the spec of urange to be in
           css3 fonts

  TabAtkins: There's several issues here. The location of the
             <urange>, I don't care where it's defined. I put it in
             syntax because it's a spec I edit and it's a weird
             complex thing that I put with a bunch of other weird
             complex things, but if you want it in Fonts, fine.
             Don't care.
  TabAtkins: If you want it in fonts, that's fine. Not an issue.
  TabAtkins: You also said it's incorrect, but you haven't pointed
             out where. I ported the definition of the old parsing
             and modified it in a few small places. It should be as
             correct and match the old unicode-range. We don't
             accept wider or narrower then the old version.
  TabAtkins: The definition itself is ugly, I agree. This is what
             happens when you mix syntaxes.
  jdaggett: It's not necessary.
  TabAtkins: It is. You can't use the existing Font spec that
             defines roughly how it looks because it doesn't map
             into a string of tokens properly. It's ugly and
             terrible and that's why it says this isn't for authors
             to read and I have a note to read other bits and that
             this bit is just for implementors.
  <fantasai> You could put it into an appendix

  jdaggett: You're not giving precise mapping. If you look at the
            algorithm it just says reinterpret as these other things.
            The grammar is so complex because the syntax is hairy
            and we can't it capture easily. What you wrote is what
            an implementor will get from the existing test and this
            doesn't add clarity.
  TabAtkins: The token definitions I've pulled out are non-obvious,
             but they are what an implementor needs to recognize.
             Asserting we don't need to write that is wrong. We
             absolutely need to write that or each implementor will
             need to recognize those independently.
  <zcorpan> I agree with TabAtkins on the above.
  jdaggett: What's my objection is that the grammar is useless. The
            algorithm isn't whats used, it's saying reinterpret as
            hex digits.
  TabAtkins: That's what we need when we remove the old version.

  <ChrisL> So why was the special token removed? Why not have an
           opaque blob for that one thing?
  <dbaron> ChrisL, because it matched things that it wasn't supposed
           to match, like some selectors
  <ChrisL> thanks, dbaron
  <dbaron> ChrisL, we were having trouble telling authors why u+i
           was a valid selector and u+a was not
  <zcorpan> ChrisL e.g. u+a {}
  <ChrisL> got it

  dbaron: I think we need to say how a token stream needs to be
          interpreted. I think part of the controversy was TabAtkins
          making changes about what's valid and invalid.
  TabAtkins: Which I dropped back from. I found it easier to do
             explicit parsing that matches the old text. It matches
             everything it did before. Nothing that didn't match
             before matches now.
  jdaggett: dbaron, why do you think the algorithm is necessary?
  jdaggett: The production will be longer than it is now.
  dbaron: It will, yes.
  TabAtkins: If we were doing this today we wouldn't use this syntax.
             We would use something more compatible. We're stuck
             with it. It's fine. It's nice and usable. However
             describing it in syntax now that we've removed the
             token, it's messy, but that's for implementors to deal
             with.
  TabAtkins: Developers doesn't have to worry about the messy, they
             get a nice simple way.
  <jdaggett> u+2f3f? is not captured with the current syntax

  Florian: One question. Even though it's hard, can you have the new
           syntax be separate? Is this approach useful or redundant?
  TabAtkins: Depends on how much work you're willing to do.
  dbaron: And how precise the other text is.
  Florian: So having two definitions that say the same thing, is
           that useful? Maybe making one an informative note
           explaining the other.
  TabAtkins: The pretty author text, that's the informative. The
             normative is the algorithm.
  fantasai: We might want it in an appendix, also.
  TabAtkins: That's reasonable.

  <dbaron> I think the complexity of expressing this makes me wonder
           if we should instead keep the token and teach selectors
           how to handle unicode-range tokens as selectors.

  jdaggett: It's basically useless information. I think we need to
            allow for variations in number of tokens, blah blah blah.
  TabAtkins: That's captured by dimension with optional ? clause.
  jdaggett: That's 2F3. How's that captured.
  TabAtkins: It's a valid dimension.
  <zcorpan_> u+2f2f? -> IDENT(u) DIMENSION(+2, f2f) DELIM(?)
  jdaggett: This isn't helping anything. An implementor is thinking
            the algorithm and what are the set of tokens I'm getting
            and I'll reinterpret as a string. The algorithm captures
            existing syntax.
  <SimonSapin> As an implementer: yes, making this weird messy
               grammar explicit is useful
  TabAtkins: That's the point. The point is to describe the syntax
             in terms of CSS language. I think you're imagining that
             implementors can just image the underlying pieces. If
             unicode is defined as a higher level, I need to define
             it in terms of tokens.
  TabAtkins: You're arguing for us to reintroduce the unicode-range
             token. That's what we don't want because it's a complex
             structure that's interfering. So we're left with this
             messy one.
  jdaggett: You're describing what the spec could describe by saying
            instead of unicode-range, there's this, this, and this.
            You've described it and the extra description doesn't
            help anyone.
  TabAtkins: Except implementors who want to be interoperable.

  Florian: I think at this point TabAtkins and jdaggett's positions
           are clear. I think we need to hear from other people.
  SimonSapin: As an implementor it helps to have the token explained.
  jdaggett: Why?
  SimonSapin: It's what I need to implement.
  dbaron: If we remove the token, we need this. However, I'm having
          second thoughts on removing this. We need to leave it and
          teach selectors how to deal.
  ChrisL: How would you do that?
  TabAtkins: The selectors would need to interpret some types of
             urange as one type selector plus another type selector.
             That's not for all uranges.
  TabAtkins: If we need the ugliness somewhere, I'd rather isolate
             it into the one place it needs to be. Since I have to
             write a proper parse of Selectors, I dread having to
             deal with this.
  plinss: I agree.

  dbaron: One of the things that is level breaking about TabAtkins
          proposal is it requires remembering textilization of
          unicode tokens.
  TabAtkins: That's already required for hex colors.
  dbaron: I don't remember having to do that.
  <zcorpan> dbaron gecko isn't interoperable with IE on hex colors
            in quirks mode. quirks spec sides with IE currently
  <zcorpan_> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
             http://w3c-test.org/quirks-mode/hashless-hex-color.html
  TabAtkins: The quirks spec has a funky thing. It needs to spec a
             hex color without the hex in front. So to do that you
             need numbers and idents so you don't drop the leading
             zeros.
  Florian: There's a comment saying Gecko isn't compatible with IE
           on this.
  TabAtkins: I think we are compatible with IE last I remember.
  <zcorpan_> 123 = #112233 in IE/spec, but #000123 in gecko/blink

  plinss: So we have disagreement as to if this needs to be there,
          but several implementors want it there. I think we have
          agreement this should be in font spec as an appendix. Can
          folks live with that?
  jdaggett: I'm fine with an appendix.
  plinss: Objections?
  jdaggett: With the caveat where I think this can be simplified.

  RESOLVED: Move this definition to an appendix in the Fonts spec

  <zcorpan> dbaron i guess the quirk spec could be changed though
  <TabAtkins> Ah, so we're compat with Gecko. Interesting.
  <TabAtkins> But I tend to suspect that quirks compat leans heavier
              toward the IE result.
  <zcorpan> TabAtkins possibly but clearly we can get away with not
            matching IE here
  <TabAtkins> zcorpan, sure. We don't *need* numeric representation
              if dbaron is okay with allowing U+00000000000002 being
              valid and equivalent to U+0002.
  <TabAtkins> Oh, well, I suppose I'd need to record some more flags
              from scinot numbers.
  <TabAtkins> Right now I translate them directly into numbers. If
              we drop the representation, I'll need to record that
              they were scinot and what power they had.
  <zcorpan> TabAtkins dbaron maybe we should explore killing
            representation of tokens if having the representation is
            bad
  <TabAtkins> zcorpan: I know that our implementor switching us to
              the Syntax spec wanted to avoid using representation,
              for memory reasons. It would be nice to avoid.
  <SimonSapin> TabAtkins, +1 to dropping number representation if
               possible

CSS3-UI
-------

  Florian: A bunch of small issues, but maybe not too small. The
           first was discussed at TPAC, but not resolved. Drop the
           definition of pseudo classes because they're better
           defined in Selectors.
  Florian: There's also pseudo-elements. I have two separate points,
           first one is pseudo-classes are in Selectors 4 and are
           either identical or have clarified language.
  Florian: We kind of agreed, but didn't record a resolution. Maybe
           its been resolved already, but I don't think so.

  plinss: Objections?
  <andreyr> no objection
  tantek: No objections. I think this does need different review
          from the normal element tree for reasons like the
          valid/invalid experience we had. No objections to moving
          them to Selectors 4, I want to figure out how we get more
          and earlier review to fix them.
  tantek: I guess that's more of a request for input instead of a
          proposal.
  tantek: My comment also applies for moving the pseudo-elements to
          the pseudo-elements spec. So that same comment/request
          applies.

  Florian: So can we resolve on pseudo-classes and move on?
  plinss: Objections?

  RESOLVED: Move pseudo-classes from CSS3-UI to Selectors 4.

  tantek: And this is just for existing ones?
  plinss: I think in general pseudo-classes should be in some level
          of selectors.
  <fantasai> http://dev.w3.org/csswg/selectors4/
  fantasai: New ones have been dropped into selectors 4. We just
            never removed those.
  tantek: So I'd like that recorded as well.
  Florian: I'm having a hard time hearing, but I think I'm okay with
           what I've heard.

  RESOLVED: For clarity, all future pseudo-classes should be in a
            Selectors module

  tantek: Should we do the same with pseudo elements, and move them
          to the pseudo element spec as well?
  Florian: For pseudo-elements, I'd agree with tantek's suggestion
           if we were to keep them at all, but I suggest we drop
           them entirely since they only apply to XFORMS.
  <ChrisL> xforms is not really relevant anymore
  Florian: Bert was tasked with...we lost tantek
  * Florian waits for tantek to get back online

  glazou: I don't think there's a single XFORM with a pseudo-element
  <Bert> (I checked the most likely implementations and did not find
         pseudo-element support.)
  <Bert> (Except for XSmiles, which is not maintained.)
  plinss: I'm not clear is tantek is trying to get back.

  Florian: So Bert reported it hasn't been used since 2008.
  <ChrisL> drop it
  Florian: I contacted betterFORMS which had been suggested on the
           list as an XForms implementation potentially using these
           pseudo elements. They don't use them, nor do they know
           anyone who does. They covert XForms into HTML and style
           that. So with no known implementations, I suggest we drop
           them instead of moving them.
  glazou: I agree with that.
  plinss: Anyone want to keep 'em?
  <Florian> Tantek?

  RESOLVED: Drop XFORMS related pseudo-elements.

  Florian: Unfortunate that we lost tantek
  plinss: We'll revisit if he objects.

  Florian: Similarly the icon value and property don't have
           implementors and there's no interest. So I suggest we
           drop them.
  plinss: Push to level 4 or drop entirely?
  Florian: I think drop, but I can push if there's interest. So far
           I've found no interest.

  plinss: implementors? Anyone want to implement this?
  Florian: I asked on the list and Google and Microsoft were no if I
           remember correctly.
  Florian: Yes, TabAtkins and gregwhitworth say no plan. No other
           comments.
  dauwhe: These were in Generated Content and had no interest either
  <ChrisL> drop
  smfr: I don't think webkit has interest.
  plinss: So drop entirely?
  Florian: We can pull back if someone becomes interested.
  <smfr> drop
  dauwhe: I'd say drop
  <andreyr> drop
  glazou: drop

  RESOLVED: Drop content: icon and the icon property

  Florian: Last drop request is the nav-index.
  Florian: Directional nav properties are fine, but the index has
           problems. This has a bit of interest, so I'd suggest move
           it to level 4, but I think it would hold back CSS3-UI
  dbaron: We had various discussions with WAI about this. I don't
          know if they'd be upset about moving to 4, but we should
          get the results of that discussion in somewhere.

  ChrisL: Florian, you mentioned some interest?
  Florian: I vaguely remember that the same people with interest in
           directional nav had interest, but I don't remember
           exactly who.
  <ChrisL> that argues for moving to level 4 rather than dropping,
           then

  <tantek> I've been tracking "future" / "postponed" UI related
           pseudo-classes and pseudo-elements here
           https://wiki.csswg.org/spec/css4-ui#more-selectors
  <tantek> gah
  <tantek> is my IRC getting through at least?
  <tantek> ???
  * smfr tantek yes
  * Bert sees Tantek on IRC
  <dbaron> tantek, just got 4 lines at once

  <tantek> It's in the CSS3-UI issues page folks
  <tantek> Could someone please check that instead of wondering
           where it is?
  <tantek> Search https://wiki.csswg.org/spec/css3-ui for nav-index
  <tantek> It links to various discussions and things,
  <tantek> since searching email fails.

  glazou: In terms of TV, people are more interested in direction
          then index. If it's implemented it's not used and I'm not
          sure if it's implemented everywhere.
  fantasai: I remember some discussion about nav-index and the
            problem was it's global to the page with no hierarchy.
            If we can we should try and fix that. It seems that
            would be better in 4.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0364.html
  <fantasai> glazou's email that was this investigation^
  glazou: The problem is the use case. Last time I read about that
          it said this is useless because people are using the arrow
          keys on the remote.
  glazou: I think we ping these people to find out if it's used. If
          it's unused we should drop it and it's worthless to invest
          time. People have implemented the direction nav, but not
          the others.
  fantasai: And we're not talking about dropping direction.
  glazou: I don't think anything but direction is used.
  Florian: People still discuss it, so I don't want to drop
           completely, but we can push to 4 and discuss again when
           we try and stabilize that. If it's clear no one wants it
           we can drop immediately. I'm fine with either.
  <fantasai> minutes from last nav-index discussion with a11y folks:
             http://lists.w3.org/Archives/Public/www-style/2011Nov/0712.html
  fantasai: I'd like to push to level 4 with an issue about the
            things brought up at the last a11y disucssion.

  Florian: tantek you're back?
  tantek: Yes.
  Florian: So, the question is, do we drop nav-index now, or move it
           to level 4, or stabilize it now. No one seems in favor of
           stabilizing it now
  tantek: I haven't seem implementors interested. The potential
          opportunity is to fix it and make it better then tabindex
          because it doesn't have backward compatibility problems.
          And the folks with directional nav stylesheets could use
          it in the same stylesheet. If that's interesting enough I
          think we can put it into level 4. If there's no interest,
          we can drop.
  tantek: I'll move the text to a wiki and let it evolve passively.
  tantek: So does anyone in the group, especially those with the
          directional properties, have interest?
  <ChrisL> (it seems not)

  <tantek> for reference: https://wiki.csswg.org/spec/css3-ui?&#issue-25
  <tantek> please add more URLs there
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg440
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg441

  glazou: The implementors I dealt with during my time at Samsung
          had no interest in nav-index.
  Florian: I don't remember for Opera. I don't think they have
           stated not being interested, but they haven't expressed
           interest loudly either.
  tantek: That's important data. I'd also like to hear from
          TabAtkins who looked at tabindex. Is it worthwhile?
  TabAtkins: I don't think so. I think we should fix HTML and then
             CSS.
  tantek: Okay, so I'd rather it move to W3C wiki with other
          semi-abandoned properties so if anyone else wants to get
          it later, it's good.

  <Bert> q+ to suggest asking WAI PF for a joint telcon or at least
         advice

  stevez: It seems to me that at the protocol group someone talked
          about the nav-index so check with him to see if there's
          interest. The question is if they thought it would fix
          tabindex.
  fantasai: I linked the F2F discussion. They brought up a lot of
            problems, I'm not sure how much it was "I want this"
  tantek: fantasai, can you add your urls to this wiki page?
  dbaron: I also linked to the follow-up threads.
  <tantek> Please add your URLs about nav-index here:
           https://wiki.csswg.org/spec/css3-ui?&#issue-25
  <tantek> dbaron and fantasai ^^^
  <dbaron> tantek, there's also a separate
           https://wiki.csswg.org/ideas/nav-index

  Florian: There seems to be consensus on moving this to a wiki.
  plinss: sounds reasonable.
  tantek: If you care about it, put it on the wiki

  RESOLVED: pull nav-index from level 3 and put it on a wiki

  Florian: One more. There is a clarification that we need on
           text-overflow. The prose seems to be contracting itself
           when the property is used with a single value and you are
           scrolling the thing that's being ellipsed.
  Florian: The text appears to be contradicting as to if it applies
           to both sides or just on the end side. Implementations do
           end side only. If you have double value it's fine.
  tantek: This isn't a one minute issue. I believe there was
          discussion on this with fantasai two years ago we got this
          to work with Gecko. If the spec has prose problems, I'm
          going to go with Gecko.
  tantek: At the time our tests showed no other implementors, IE,
          Webkit, or Presto were even trying to do something
          interesting.
  Florian: Presto does the same as Gecko for the single value, and
           does not support double value. Others don't do anything
           interesting indeed.

  Rossen: This isn't one minute. It's a good topic.
  Florian: I agree. We can't do this now.
  tantek: Continue offline.

  <tantek> we didn't get to :has-focus either - on that topic please
           review *all* the new CSS UI related selectors being
           considered/implemented:
           https://wiki.csswg.org/spec/css4-ui#more-selectors

Box-Tree API
------------

  plinss: One quick topic myself. We've had some discussions about
          creating a taskforce for the box-tree API. I don't think
          we have a resolution for it.
  plinss: Objections?
  <ChrisL> +1
  <dauwhe> +1
  <sgalineau> +1

  RESOLVED: Create a taskforce to work on box-tree API and
            extensible CSS APIs

  tantek: I want to point out we didn't get to :has-focus. There's a
          whole bunch of CSS Selectors being implemented. I dropped
          a link above, give it a look.

  plinss: That's it for the week, thanks everyone.

Florian Rivoal | 20 Nov 18:17 2014
Picon

[selectors] applying pseudo classes to the label based on the labeled control

[selectors] gives to the host language the ability to define additional ways for :hover and :active to
match (other than being the directly hovered or active element, or its parents). HTML uses that to make the
state apply to a labeled control if it applies to its label (<label for=“foo”> and <button id=“foo”>).

I believe that having this work in the other direction as well (apply to the label if it applies to its labeled
control) would make plenty of sense, and that it should apply (at least to) to :hover, :active, and the
:has-focus pseudo-class currently being discussed in another thread[1]. Having this apply to the input
pseudo classes[2] might make sense as well. Requests for styling the label based on the control are
frequent enough[3][4][5][6].

As CSS defers this to HTML, I raised this at the whatwg[7], but this has been met mostly with indifference,
and with a bit of push back (from Boris Zbarsky and Ryosuke Niwa, both CCed). I am bringing the discussion to
the csswg, as there is a higher density of people who care about selectors here, so we can bash it out here
before either dropping it or sending it back to the whatwg with stronger back up.

The concern expressed (Boris and Ryosuke, correct me if I am wrong) is that since the relationship between
labels and labeled controls is n-to-1, there are performance implications to doing it from the control to
the label that are not present when going from the label to the control, and they’re concerning enough
that this could outweigh any benefit.

However, IE already behaves this way for :hover and :active. I checked with microsoft, and the result of
their investigations is that "there is not a single bug filed against IE regarding performance issues by
tying the the label to the labeled control”. Absence of proof is not proof of absence, but this does
provides good evidence in support of performance being manageable, especially since :hover is the most
performance sensitive of the bunch.

Using :has() is not a viable alternative, because:
1) :has(), not being part of the fast profile, must not be supported by UAs for CSS selection
2) even with :has(), the relationship between a label and its labeled control in arbitrary markup cannot be
expressed with existing selectors

Even if we solve both points above, the performance of doing it with a generic mechanism like :has() would
undoubtedly be worse than the specialised behaviour I am proposing.

So, what does the csswg think?

[1] http://lists.w3.org/Archives/Public/www-style/2014Nov/0271.html
[2] http://dev.w3.org/csswg/selectors/#input-pseudos
[3] http://stackoverflow.com/questions/4388102/can-you-style-an-active-form-inputs-label-with-just-css
[4] http://stackoverflow.com/questions/5978239/anyway-to-have-a-label-respond-to-focus-css
[5] http://stackoverflow.com/questions/19362716/how-to-style-a-html-label-for-disabled-input
[6] http://lists.w3.org/Archives/Public/www-style/2013Jul/0294.html
[7] http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0073.html

 - Florian

Benjamin Poulain | 20 Nov 03:03 2014
Picon

[selectors] :matches() with pseudo elements

Hi all,


Yusuke Suzuki has completed the initial implementation of :matches() in WebKit. He recently included support for pseudo elements.

There are still some edge cases we are working on, but globally everything works great so far. I think we should drop the pseudo-elemen t restriction from the definition of :matches().

Benjamin

Gmane