Koji Ishii | 3 May 19:21 2015

[css-text] Halfwidth Katakana and symbols in UAX#14

UAX#14 Unicode Line Breaking Algorithm[1] currently defines that:

1. Halfwidth Katakana letters (U+FF66, U+FF71-FF9E) as AL
2. Halfwidth with General Category=So/Sm (U+FFE8-FFEE) as AL

and Makoto Kato asked Unicode if it's appropriate to change #1 to ID. I support his proposal, and also I suppose #2 should have the same classes as their non-compatibility counterparts.

Since this has been defined so for 15 years, Unicode is interested in what CSS WG and implementers would think, including if the change could have adversely affects.

Thoughts? Can we resolve the response to Unicode?

Some additional information follow:

1. For #1, IE and FF already tailor to ID. Chrome and Safari follow UAX#14 today.
2. MS Office, RichEdit, NotePad, etc. tailor to ID. OS X TextEdit follows UAX#14.
3. Other Halfwidth characters are:
  a. Halfwidth Hangul letters (U+FFA0-FFDC) are AL, and I think should be unchanged
  b. Halfwidth small Katakana are CJ, and should be unchanged
  c. Halfwidth punctuation (Po/Ps/Pe) are CL/OP/NS, and should be unchanged
  d. Halfwidth Lm are CJ/NS, and should be unchanged


Koji Ishii | 3 May 15:37 2015

[css-writing-modes] Orthogonal parent's logical width

I read Orthogonal Flows[1] several times but as far as I understand, it does not define how to calculate parent's logical width (i.e., children's logical height.) It describes relationship of children's logical width and parent's logical height though.

I'm assuming, after children was layout and children's logical height was determined, it becomes both min-content and max-content of logical width for the parent. Is this correct?

I have a bug in Blink related with this, appreciate to know if my understanding above does not seem correct.
Cameron McCormack | 1 May 03:40 2015

[css-font-loading] load, check and testing for character coverage

I have a few questions/comments about load and check and the tests that
are done for character coverage using the sample text string.


The “find the matching font faces” algorithm will not include a matching
font face in its return value if its unicode-range does not include at
least one of the characters in the sample text string.  The algorithm
reads like it is written assuming that all font faces have a
unicode-range attribute, but that isn’t true for system fonts.  Should
we be checking the actual cmap of the font to see whether we have a
glyph for a given character?

For example, assuming Helvetica is a system font:

  document.fonts.check("16px Helvetica", "上")

Should this return false, because the font does not have a glyph for the
specified character, or should it return true as if we treated system
fonts as having an unspecified unicode-range (and therefore covering all


For that matter, should a font’s cmap ever affect how load or check
operate?  If I did:

  var f = new FontFace("Test", "url(Ahem.ttf)");
  f.load().then(function() {
    alert(document.fonts.check("16px Test", "上"));

per spec I think this should alert true.  It’s a little confusing, since
the author might think check is actually checking whether we will be
able to render the given string without using a fallback font, but
really what it’s doing is determining whether attempting to render that
string will need to kick off any loads.

I don’t know if the name “check” describes the behaviour of the method
clearly enough.


In line with the check method meaning “will loads be kicked off”, I
think it should return true if the list of matching font faces is empty.


Cameron McCormack ≝ http://mcc.id.au/

Florian Rivoal | 30 Apr 17:17 2015

[css-ui-4] user-modify


After specing user-select and appearance, I've looked at user-modify as another legacy feature
originating in early version of CSS-UI[1] that has some amount of browser support, and might deserve a specification.

However, my personal conclusion is that we should not be standardize it, and I'd like to hear whether the
csswg agree.

Here are my reasons:

1) It is only supported in Webkit/Blink. Despite what MDN claims[2], Mozilla does not have an
implementation [3], and despite some rumors here and there on the web[4], neither does IE. So there isn't a
major argument that it is needed for compat reasons.

2) It goes against the idea of the separation of concerns: this is tightly coupled with other things in html
and js, not with other things in css. CSS-UI does have a few things that are arguably not stylistic, for
example 'nav-*' or 'resize', or user-select, but these do have a stronger coupling with other things in a
stylesheet. user-modify is more strongly coupled with the content and with js than it is with css.

3) Having this as a CSS property does not enable anything you cannot already do in HTML with
contenteditable. contenteditable takes both a ''false'' and ''true'' value, matching
''user-modify:read-only'' and ''user-modify:read-write'', and even takes ''inherit'', so we're not
even missing inheritance. Webkit does have an extra value (read-write-plaintext-only), but there's no
reason that couldn't be a value of contenteditable, so that's not a justification for having this feature
in CSS.

5) Having this as a CSS property suggests you could use it on non HTML documents (SVG, arbitrary XML...), but
the processing model for contenteditable is defined in terms that are only meaningful in an HTML
document, so it cannot be applied elsewhere as is. Defining a generic mechanism in CSS that would apply to
any language sounds hard, and if CSS just defers the meaning to the host language, I don't really see what it
is bringing to the table.

6) Using it in a user style sheet doesn't seem like it would enable anything useful. There's no strong
requirement that css properties have to be useful in user stylesheets, but if it had been useful, it would
have been a hint that having it as a property could be a good match.

In my mind, the only nice thing about it compared to contenteditable is that you can use selectors to place
it, and selectors are a neat tool. But since contenteditable is unlikely to be used without JS (to use the
edited content) and JS has querySelector() and friends, you can use selectors with contenteditable
anyway, so I am not convinced this matters.

This isn't to say that contentEditable is bug-free or completely figured out. Far from it. But I believe
standardization and implementation effort would be much better spent on contentEditable than on

- Florian

[1] http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-modify
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-user-modify
[3] http://logs.csswg.org/irc.w3.org/css/2015-04-01/#e538914
[4] http://stackoverflow.com/questions/22226868/contenteditable-v-s-user-modify

Dael Jackson | 30 Apr 15:07 2015

[CSSWG] Minutes Telecon 2015-04-29

Paris Houdini F2F

  - Rossen confirmed that the Houdini task force would be meeting 28
      and 29 August after the CSS F2F hosted by Mozilla.
  - If anyone is planning on attending, please add their information
      to the wiki: https://wiki.css-houdini.org/planning/paris-2015

Rounded Displays and Flexbox

  - Most of the group was supportive of an exploration of the
      relationship between flexbox and rounded displays.
  - It was agreed that this didn't belong in level 1 of flexbox, but
      should instead exist as an exploratory section of the rounded
      displays spec and/or a wiki and mailing list thread with the
      conclusions potentially being integrated into flexbox 2.

 <at> media not

  - RESOLVED: In media queries, use 3-valued logic with maybe semantics
              to handle unsupported syntax, i.e. false and unknown =
              false. (Re-evaluate if this ends up with back-compat

AnimationEnd events and display: none

  - RESOLVED: No animation events when subtrees are destroyed.
  - RESOLVED: Start a next level of transitions with dbaron as an

/deep/ combinator

  - RESOLVED: Drop /deep/ from dynamic profile and record an issue
              about keeping it in the static profile.

Splitting up the Containment Value

  - RESOLVED: Do layout containment, split containment into three
              pieces as per TabAtkins' proposal
              and have overflow: clip


  - It was agreed that the coordinate systems need to be better
      defined, but that the definition belongs in CSS Image.
  - The CSS Image authors will do more research and create edits to
      the spec and CSS 3 UI will reference CSS Image.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Peter Linss
  Michael Miller
  Edward O'Connor
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Hyojin Song
  Alan Stearns
  Steve Zilles

  Sanja Bonic
  Brad Kemper
  Greg Whitworth

  scribe: dael

  plinss: Let's get started
  plinss: Anything to add?
  Rossen: I have one.
  Rossen: Just an update about the Houdini meeting in August.

  plinss: Anybody else?
  bcampbell: I am going to NY as long as we can talk about some of
             the things we spoke about earlier with flexbox. I'd
             like to know who to speak to about the agenda for the
             NYC and if we can set aside some time for the a11y and
  plinss: Generally for a F2F there's the wiki and you can feel free
          to edit that and add topics and we schedule exact times at
          the first day of the meeting.

Paris Houdini F2F

  Rossen: Mozilla has agreed to host us and the meeting will take
          place Fri and Sat following CSS with ends on Thursday. I
          don't have a calendar but I believe that's Aug 27 and 28.
          So please, there is a wiki set up so if you haven't please
          sign up. That's about it.
  <dbaron> It's August 28-29.
  <dbaron> https://wiki.css-houdini.org/planning/paris-2015
  Rossen: Any questions?

  plinss: First two items on the agenda were resolved.

Rounded Displays and Flexbox

  <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0064.html
  TabAtkins: I'm mildly opposed to doing new rounded display stuff.
             I want to wait for everything else to catch up and
             exist. Especially for expansions to flexbox which would
             be complicated.
  Rossen: Why would you assume these would be in the current flexbox
  TabAtkins: They don't have to obviously but then we're working
             further into the future than we'd like.
  Rossen: That's kinda preventing or slowing the work of rounded in
          favor of existing flex or grid, I don't feel I'm okay with
          that. I think it's worthwhile to keep in mind rounded
          displays as we make progress and close on flex and grid
          with the mind where we're not preventing anything for
          rounded completely.
  Rossen: However, I don't want to delay these specs for rounded.

  glazou: This is a surprise to me. We didn't let hyojin go first so
          he can explain why this is a good match. I'd like to hear
  * glazou notes that another major vendor announced rounded
           displays this week : samsung...
  * Florian saw that too. Happy that LG is leading the
  hyojin: I'm pleased to meet you. I see the flexbox spec, I think
          it is related to round display. I'm wondering is it right
          to progress on finding round display now.
  hyojin: I don't know about the progress of flexbox.
  fantasai: I think exploring how flexbox and rounded work together
            in better ways is worth exploring. We can't do that in
            current flexbox, but the rounded display module can have
            an exploratory section for flexbox and in that case when
            things become more settled we can put it into flexbox
            level 2. It's good to explore these things and to see if
            these settings you're prop solve the problems.
  fantasai: If we get to a point where we're ready to add to flexbox
            we can start a level 2
  hyojin: If it's reasonable to progress, I can describe properties
          or technology. I can prepare those things. I don't want to
          delay flexbox spec progress.

  Florian: I don't know if we can directly reuse the flexbox
           properties, but at least reusing the concepts certainly
           sounds useful. Polar coordinates as proposed in css-round-
           display suffer from the same kind of problems as abspos
           in terms of collision. Having flexbox-like abilities to
           decide which elements should stay fixed size, and which
           should grow or shrink depending on available space sounds
           useful. I don't know exactly how that would work, but it
           certainly is worth exploring.

  <tantek> was going to say the same thing about polar coordinates
           and flexing. Thanks Florian :)
  <TabAtkins> In general, I'm mildly opposed to new display modes in
              general ("round flexbox" is effectively something new
              compared to "flexbox"), as I think we should just
              focus on custom layout, and *then* only develop new
              layout modes that are proven to be popular in practice.

  tantek: [expresses a desire to see use cases or diagrams about the
          desired effects of the combination of rounded display and
  <fantasai> tantek++
  <tantek> would be nice to see a separate draft that documents
           diagrams and use-cases of the desired design effects
  <tantek> and that can better inform our discussions

  Scribe: TabAtkins

  hyojin: I agree that Flexbox level 2 is a good place to start
          thinking about rounded display.
  Florian: I agree with tantek that seeing diagrams or use-cases
           would be good. I'm not sure it should be a draft yet; a
           mailing list or wiki would be more appropriate.  But
           regardless, having some examples would be very
  plinss: Agreed.
  hyojin: Okay.
  <tantek> (and yes - format draft/wiki/email is up to author)

 <at> media not

  Florian: On the call it seemed like a good idea to have 3-valued
           logic to deal with unknown media features or general-
  Florian: On the ML, though, we realized there are two different
           types of 3-valued logics we can use - a "maybe" or a
  Florian: "maybe" makes more sense, but has a greater chance of
           breaking backwards compat.
  Florian: Tab also proposed a 4-valued logic with both values, but
           it's probably too complex.
  TabAtkins: I agree that it's too complex.
  * fantasai is confused, but will be satisfied if dbaron thinks the
             proposal is sane
  Florian: I'd prefer to go with "maybe"; it's nicer, and I think
           the compat risk, while it exists, is moderate.
  Florian: But if browsers disagree, then we should use "bottom".
  Florian: The difference between "maybe" and "bottom" is that if
           you have "(false-thing) and (maybe-thing)", it's false.
           If you have "(false-thing) and (bottom-thing)", it's
  Florian: False and unknown being unknown is safer for backwards
           compat. but false and unknown being false is a nicer
           system to work with.
  TabAtkins: Yes, because it preserves De Morgan's laws.

  Scribe: dael

  fantasai: False and unknown = unknown is bottom. Other is maybe.
            Maybe makes sense to me.
  Florian: But maybe semantics are less backwards compat.
  TabAtkins: The ones that were problems, in MQ 3 semantics it
             became not all. In the new semantics the prefix would
             be a 'maybe' or 'bottom', then a not screen and when
             screen is false when printing you have the same problem
             with a big 'not' negating everything.
  <fantasai> The example was "not screen and (-webkit-foo)"
  <fantasai> Which would evaluate to true when printing
  <fantasai> But is currently thrown out by non-webkit browsers
  TabAtkins: When false and bottom equals bottom it stays false when
             exiting which matches MQ3 semantics. It looks to be
             very very rare. In order to get it you have to have a
             MQ starting with 'not' and a prefix thing ending with
             it. It happened twice in the database we looked at.

  TabAtkins: Unless somebody feels bad with this I'd like to go with
             'maybe' and allow, if necessary, to change to bottom
             later. I think the compat risk is small enough we don't
             have to worry.
  fantasai: That makes sense to me, I'd like dbaron's take on it.
  TabAtkins: Okay.
  <dbaron> I don't really have an opinion (right now, anyway)

  plinss: Objections?

  RESOLVED: In media queries, use boolean maybe semantics to handle
            unsupported syntax, i.e. false and unknown = false. (Re-
            evaluate if this ends up with back-compat problems.)

AnimationEnd events and display: none

  TabAtkins: If you have a running animation and a display: none it
             stops, but does it throw an end? Currently browsers
             don't. Later if we add animation cancel events that
             will change the subtree. Right now no events get fired
             when an animation stops due to a display: none
  smfr: I agree with that.
  <andrey-bloomberg> no issues
  dbaron: I agree as well, though I have a follow up.

  RESOLVED: No animation events when subtrees are destroyed.

  dbaron: Are people okay with starting the next level of
          transitions and animations where we add in cancel events?
  <dbaron> transitionstart, transitioncancel, animationcancel
  <dbaron> (and as a delta spec)
  plinss: Any objections?
  <astearns> +1 to new diff draft
  Rossen: Go ahead
  <glazou> +1 to what dbaron said

  RESOLVED: Start a next level of transitions with dbaron as an

/deep/ combinator

  TabAtkins: In the recent shadowDOM meeting there was discussion on
             simplifying. One of the conclusions was the ability for
             CSS to easily reach into shadows like this is probably
             bad. They resolved to remove that combinator. The other
             option is removing from dynamic profile. A few people
             preferred that. So either removing it or just having it
             in the static profile.
  TabAtkins: I'm not sure if we need to resolve, it might be better
             to let webapps decide, but we need to be aware.
  plinss: That's why I added it to the agenda, to have discussion.
  TabAtkins: Related there are simplifications to shadowDOM to make
             it a bit easier.
  plinss: Other thoughts or opinions on shadow combinators?
  <glazou> +1
  hober: It was a strong consensus to drop /deep/ I'd rather that
         than keep in static.
  plinss: I tend to agree. There was discussion in TAG and the
          opinion is people want a better module to describe the
          style instead of reaching into the DOM. It might be
          dangerous to keep this.
  TabAtkins: The reason people argued for it is there's nothing
             preventing you from walking the DOM manually. The point
             it to make that unnecessary. It doesn't expose worse
             information, it just makes it possible to do from the
             query selector. We can discuss that with webapps.

  fantasai: So no resolution on that?
  TabAtkins: I'm not seeking a resolution.
  plinss: Did you want one fantasai?
  fantasai: If we have consensus I think we should resolve
  Florian: I think we have it on dropping from the dynamic profile.
  fantasai: So maybe mark it as an issue.

  RESOLVED: Drop /deep/ from dynamic profile and record an issue
            about keeping it in the static profile

Splitting up the Containment Value

  <Florian> http://dev.w3.org/csswg/css-containment/
  <plinss> https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html
  TabAtkins: At the extensible web summit we had a nice session
             about the containment value. It came out that the issue
             in the spec where we should maybe split is something we
             should address. What I proposed is to split it into the
             3 things it does.
  TabAtkins: Layout containment, the element doesn't pay attention
             to children in terms of layout so nothing can cause
             extra layout. Paint containment so you have a clipping
             boundary. Style containment which is a couple of styles
             that can influence the rest of the document can no
             longer do that. The effects of things in the style
             element can't effect the rest of the doc like counter
  TabAtkins: These are the three general areas that the proposal
             addressed. I split this to three keywords, layout,
             paint, and style and keep the strict keyword to turn on
             all three of them. If you need to be flexible in some
             ways you can just turn on what you're okay with.

  Florian: First you say split everything in the sec, but the spec
           currently doesn't have layout containment right now and I
           really want that.
  TabAtkins: That was an oversight on my part. It'll be there.

  Florian: For paint containment, it does three things. Do the same
           as overflow: hidden, don't allow scrolling, establish a
           containing block for abspos and fixedpos
  TabAtkins: It doesn't do anything with scrolling.
  Florian: If you define the way you have you can get clip overflow
           without the ability to scroll with containment: paint and
           overflow: visible, and clip overflow with the ability to
           scroll using containment:paint and overflow: auto. What
           you don't get the ability to do is containment: paint
           and overflow: visible, but still be able to use properties
           like overflow-text and resize, which depend on overflow
           not being visible. I would suggest add to overflow:
           something, perhaps clipped, that does the same as hidden
           but with no scrolling.
  Florian: So that first if you use containment: paint and overflow
           is visible it will do clip but will allow you to resize
           and other related properties. It also allows you to do
           this without establishing a new containing block for
           abspos and fixedpos, which you couldn't do if you only
           had containment: paint.
  TabAtkins: This all makes sense. I am okay with this. So add an
             overflow: clipped and have overflow: visible if it's
             doing paint compute to overflow: clip as well.
  * fantasai suspects Mozilla has a clip value already

  smfr: Is containment supposed to effect other properties?
  TabAtkins: It has some effects, but not the computed values.
  smfr: In other cases we say it doesn't effect computed values. I'm
        worried about properties that override other properties and
        creating circularity.
  TabAtkins: This is why we track computed values on the wiki to see
             if we introduce a circularity. So far we haven't.

  <andrey-bloomberg> just my 2 cents - this is quite useful from
                     developer perspective

  SimonSapin: When we split things between style and layout in
              paint, is it something that's related to the feature,
              or just the current impl do things in a way?
  TabAtkins: Layout and paint are completely different things.
             That's not impl specific. They are usefully independent.
             We can come up with use cases that want one or the
             other. Style containment, I don't think it has an
             independent life, but having it separate works better
             for the overall design.
  Florian: I have a hard time thinking of containment style without
           layout, but I'm okay with it separate.
  SimonSapin: It's not the same as containment, but we think of
              layout transition being different than paint. That's
              impl specific though because when you animate the top
              property it requires layout, but some times you can do
              it in the thread.
  TabAtkins: The general definition of layout vs paint is somewhat
             impl specific, but in the case of contain they're
  Florian: And in the containment case, the definition isn't
  ??: Correct.

  Florian: To answer a comment from fantasai earlier, she says that
           she thinks Mozilla has this, and she's correct. They have
  <Florian> -moz-hidden-unscrollable

  dbaron: When I saw the split property I thought style was
          referring to selectors so I'm not sure the name gives a
          good sense of what it's containing. I wouldn't want
          something to refer to selectors.
  TabAtkins: Agreed.
  dbaron: I don't have a better idea on name.
  TabAtkins: I can put in style isn't an ideal name and we can
             bikeshed on the mailing list.

  plinss: Do we want a resolution on overflow: clip?
  Florian: I think we can resolve to do layout containment, split
           into three values, and have overflow: clip
  plinss: So objections to those proposed resolutions?

  Rossen: Can you repeat?
  Florian: One is to make sure the containment spec does layout
           containment. Next is split the values of containment as
           described by TabAtkins. Last is to have effects of
           containment: paint go through overflow: clip
  Rossen: Question: in overflow: clip in the case where clipping
          element isn't the containing block, will the effects also
  Florian: Overflow: clip visually does the same as overflow hidden,
           but you don't get access to scrolling.
  Rossen: In hidden your fixed element is still a fixed element and
          effects layout of the root element because there may be
  Florian: Overflow: clip alone doesn't change that, but if you do
           containment: paint it switches.
  TabAtkins: One of the main reasons is to invoke the machinery that
             relies on overflow being non-visible.
  Florian: When you do containment paint you want overflow: clip and
           the containing block.
  Rossen: And a stacking context. So this is kind of the god
  Florian: So overflow: clip does the same as hidden minus the
           scrolling and the rest of what you need for paint goes
           through the containment: paint property.
  Rossen: Sounds reasonable.
  <dbaron> That sounds pretty different from overflow:
           -moz-hidden-unscrollable, which is otherwise like visible
           except it clips overflow
  <fantasai> it should be equivalent to overflow: visible, except
             you don't draw outside the box
  <Florian> dbaron: overflow:clipped is the same as overflow:
            -moz-hidden-unscrollable as far as I can tell. But
            containment:paint invokes this PLUS the rest (containing
            blocks, stacking context)
  <dbaron> Florian, I think they're different w.r.t. establishing a
           new BFC.
  <Florian> dbaron, That's not documented on MDN.

  smfr: It needs some wording for if you try and scroll and if you
        transition to clip do you snap to the top.
  TabAtkins: I don't know if anything in visible says you can't
             scroll, but that's what it does. If it doesn't we'll
             make up language and you can reset to your scroll
             position. It'll be immediate.
  fantasai: It'll be exactly like visible but you don't draw outside
            the box.
  plinss: objections?
  <andrey-bloomberg> all for it
  plinss: To any of the resolutions.

  RESOLVED: Do layout containment, split containment into three
            pieces as per TabAtkins' proposal
            and have overflow: clip


  Florian: There aren't many issues left. Let's start with this.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0193.html
  Florian: When you specify an image for a cursor you can specify
           the coordinates of the hotspot. What they mean is obvious
           when you point to a bitmap via url(), but since <image>
           also lets you do gradients or image-set(), it's less
           obvious how coordinates work then. If you have different
           resolutions you can only set one set of coordinates.
           We need to define how it would work in all kinds of
  Florian: For gradients they don't have a natural size in pixels,
           the unit could be set so that 50 gets you in the middle.
           The way I propose we solve it is we define the coordinate
           space of every possible <image> type in css-images and
           refer to that in css-ui.

  smfr: If you set a repeating linear gradient as your cursor image
        what happens?
  Florian: The size is defined as impl dependant, through the
           "default" and "concrete object size".
  Florian: This is defined so the UA decides how big the painting
           area should be. The UA defines and then you have a size
           and coordinates, but you don't know what those
           coordinates are. I suggest that 50 is right in the
  Florian: Currently the spec says these coordinates are in the
           coordinate space but we don't define what the coordinate
           space is, but I think we should do that.

  tantek: For these more challenging image types, do we have
  Florian: I think we have at least interest in implementing or
           actual support for image-set.
  tantek: My understanding is we don't for things like gradients. I
          don't think there's browsers that support that.
  Florian: I think for image-set someone does or has intent.
  tantek: I don't think...image-set is new for browsers in general.
          I'd be surprised if they support them for cursors.
  Florian: I think someone said they want to but haven't done it.
  tantek: We might want to capture informative guidance, but I think
          normative language, I would oppose that.
  Florian: Now we have wording that doesn't mean anything we say
           it's in the coordinate space. I just suggest we defer to
           image values.
  tantek: That I agree with. I resisted specifying it in css3 ui.
  Florian: We might want a note in css3 ui, but not define. We might
           want a note on image-set.
  tantek: That's reasonable. If we have a reasonable note that
          reflects what's going to happen. Who edits image?
  * fantasai and Tab
  Florian: TabAtkins and fantasai
  fantasai: I think spec coordinates makes sense.
  <TabAtkins> I'd actually prefer we allow %s, and define that
              integers, when used on an image without coordinates,
              all refer to the start/start corner.
  tantek: Will you take an action?
  fantasai: We can to edit the spec, but we have the same problems
            in other places. We can take an action to see what Media
            Fragments is up to.
  fantasai: We need to define for CSS formats anyway.

  Action: fantasai to edit CSS Image and specify how to determine
          the coordinate system of the image
  <trackbot> Created ACTION-683

  Florian: There are some values where it's not obvious for what it
           should be, but we can get vocabulary quickly even if the
           behaviors are in the air. We can anchor to the right
  tantek: And now we can put a note in CSS 3 UI to check that draft
          for details.
  plinss: It sounds like a plan.
  Florian: So a note for now in CSS 3 UI and text is added to image.

  fantasai: For x and y can it take percentages?
  Florian: Only numbers.
  fantasai: It might make sense to spec as percentages. Especially
            if you have multi resolution, especially if you have
            pixel values.

  plinss: We don't have time to discuss it, but I have a follow-up
          on why we don't allow any lengths.
  <tantek> short answer is: current support

  plinss: We're at the end of the week. Thanks everyone, talk to you
          next week.

  <fantasai> tantek: I'm not so sure we need <length>, but I think
             <percentage> would've been more useful than <integer>.
             Maybe for the next level
  <fantasai> tantek, florian: Also, <x> and <y> should be <integer>
  <tantek> fantasai - yes to next level
  <fantasai> (in the spec)
  <Florian> fantasai: why {1,2}?

  <Florian> tantek: for the other css-ui issue
  <Florian> tantek:
  <Florian> tantek: do you mind if I just go ahead and add the may
            to the spec?
  <tantek> Florian - checking for context of "may"
  <Florian> Implementations may substitute a more language, script,
            or writing-mode appropriate ellipsis character, or three
            dots "..." if the ellipsis character is unavailable.
  <Florian> tantek: I'm just adding writing modes to the list
  <tantek> yes that looks good go for it

Manuel Strehl | 30 Apr 00:13 2015

CSS selector to better match label elements


I've been pondering a while over the following suggestion for a new
selector and, to my surprise, still think it is a necessary tool that is

<label> elements are notoriously hard to select with CSS in any
non-trivial mark-up structure, when the state of their control is to be
taken into account. Consider these frequent cases, where it is not
possible to reach the <label> element with CSS selectors, when the
corresponding <input> state is relevant:

1. <label><input> Input inside label</label>

2. <tr>
    <td><label>Good ol' tables</label></td>

3. <label>Label before input</label><input>

If you want to make the label react to the state of its associated
control, you need to rely on JavaScript to generate classes to "listen"
to. Only example (1) would be addressed by a parent selector
<http://www.w3.org/TR/2011/WD-selectors4-20110929/#subject>, e.g.,
`$label input`. Reference combinators
<http://www.w3.org/TR/selectors4/#idref-combinators> only work the other
way round, to address the control from its label: `label /for/ input`.
Case (3) is the inverse of `input + label`.

A clunky way to address a label from its input is to use :has()

    :root:has(input#foo:invalid) label[for="foo"]

But it relies on the knowledge of the ID of the <input> element, if it
has any. Case (1) above is then ruled out.

In many cases, the control element is partially or fully hidden, and the
label acts as proxy to interact with the control, loved by designers for
its independence from OS styles and ability to use `::before` and
`::after`. In certain constellations, e.g.,
handling this situation is already possible today with CSS only. Matt
Mastracci played a bit with the thought of using CSS Extensions to
expand on this:
However, robust solutions would most probably still rely on JavaScript.

So I come to... ***drumroll*** ...the proposal:

A pseudo-class :for() can provide better control over addressing <label>
elements. Its content must be a single selector or selector list
(mirroring :not()), that is matched against label.control. The
specificity of :for() is the specificity of its arguments. Examples:

    label:for([type="text"])             /* all labels with
label.control.type === "text" */
    label:for(:invalid)                  /* all labels with
label.control.invalid === true */
    label:for(:focus)                    /* label.control ==
document.activeElement */
    label:for(:disabled):for(read-only)  /* chaining :for(): labels for
disabled read-only inputs */
    label:for(#foo)                  /* label, that refers to the input
#foo */

If a <label> has no corresponding `control`, it will never match a
:for() selector. It could be matched by :not(:for(*)).

The :for() selector does not rely on any ID reference but on the
algorithm to find the control for a label outlined in
<http://www.w3.org/TR/html5/forms.html>. In later specifications it
could be extended to also match references defined in another way, e.g.,
"reverse lookup" via aria-labelledby or a[href^="#"].

I assume there will be headaches for implementors, since calculating the
relation might not be cheap. However, the gain in possibilities
justifies IMHO to at least consider, what concrete drawbacks an
implementation would yield. The :for() is initially scoped to <label>
attributes only, which should be an advantage in implementations.

What do you think?


Linss, Peter | 29 Apr 02:21 2015

[csswg] Agenda conf call 29-apr-2015

Time/Phone/SIP details available to WG Members in w3c-css-wg. See

For local times, see:

** CSS WG Members, please send regrets to Member-only list if you can't
** attend.

0. Digressions
Invited Expert Discussion

1. src Parsing of FontFace Constructor

2. "Computed value" line for text-shadow Incorrect

3. Rounded displays and flexbox

4.  <at> media not (unsupported feature)

5. AnimationEnd events and display: none

6. Removing /deep/ combinator

7. Splitting up the containment value

8. css-ui-3 issues


Koji Ishii | 28 Apr 20:23 2015

[css-writing-modes] Propose to defer orthogonal table cells

One more thing to propose to defer.

I’d like to defer orthogonal table cells to future levels.

I understand this has good use cases especially in non-East Asia, and Trident implements this at some
levels, but it is failing many tests. WebKit/Blink do not support this, and Gecko said a later milestone
than the initial release of vertical support for simple content[1].

Since Writing Modes Level 3 is the first level CSS supports vertical flow, I’d like to prioritize
stability and interoperability of simple content in this level. Furthermore, I suspect there might be
some spec work in table calculations if we really starts working on this. I think such work would fit better
in future levels.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1077521


Koji Ishii | 28 Apr 20:02 2015

[css-writing-modes] Propose to weaken upright rendering of horizontal-only scripts

I’d like to propose to weaken spec words when rendering horizontal-only scripts in upright.

One in text-orientation: upright, the proposed change is from:
  characters from horizontal-only scripts are rendered upright
  characters from horizontal-only scripts should be rendered upright

Then in the definition of “upright characters”[2], from:
  characters from horizontal cursive scripts (such as Arabic) are shaped in their isolated forms when
typeset upright
  characters from horizontal cursive scripts (such as Arabic) should be shaped in their isolated forms when
typeset upright
or we could be more descriptive how we’d like to weaken.

The motivation is that I know little about if every single horizontal-only script can really render
upright with this definition. I know there are people who knows it better than me, but a discussion of
Jonathan and Behdad[3] indicated me that there are more we need to study, and I’m afraid to define it
normatively with our current knowledge.

Further more, tests discovered that all browsers are not able to render some each own set of
horizontal-only characters in upright. Fixing all of such issues would require broad knowledge of
scripts in the world, which would require quite a work, and I think it is far beyond the basic vertical flow
that better to defer.


[1] http://dev.w3.org/csswg/css-writing-modes-3/#valdef-text-orientation-upright
[2] http://dev.w3.org/csswg/css-writing-modes-3/#typeset-upright
[3] http://lists.freedesktop.org/archives/harfbuzz/2015-April/004819.html


Rick Byers | 28 Apr 19:52 2015

Re: [css-ui-4] user-select

On Thu, Apr 2, 2015 at 10:47 AM, Florian Rivoal <florian <at> rivoal.net> wrote:
Since CSS-UI level 3 is getting increasingly stable and nearing CR,
I've just started a level 4 draft as a diff spec.

I've started by adding 'user-select', which we had deferred from
level 3:


There is general agreement between existing implementations about
which values should exist and what they mean, so I have not tried
to be creative about that.

However, the interop story is less nice when you look into the
details, as browsers disagree on the meaning of auto, computed
values, inheritance, applicability to editable elements...

The specification tries to strike a reasonable middle ground. It
tries to be close as possible to existing implementations when
they agree and make sense. When it diverges from some of the
implementations, I've either included a note saying why, or an
issue highlighting the disagreements.

I'm really happy to see this moving forward!   I'm not an expert on all the behavior of user-select, but I definitely support changing blink to match IE and FF in terms of how selections spanning different user-select regions behave.  In particular, when a drag starts on a 'user-select: none' and extends to a 'user-select: auto' element, blink/WebKit currently selects it the text in the 'auto' region.  

This has been problematic for us in a number of ways, and (without being aware of this debate in advance) I just filed a bug for us to try to change blink to match IE/FF here (http://crbug.com/481985).  In particular, it means you can get accidental selection when dragging (exasperated by our recent spec compliance fix to stop paying attention to preventDefault on mousemove for purposes of selection).  Perhaps more importantly, it makes it hard to implement text selection efficiently on pages with lots of user-select: none ranges.  It's easy to reproduce problems in practice [http://crbug.com/472258] in Chrome and Safari where adding 'body { -webkit-user-select: none; }' causes mouse dragging to be very expensive, and this has come up as an issue with, for example, games.

Also, even though as of today, only IE supports the ''element''
value, I have included it because:

* Even browsers that do not explicitly support it have this
behavior on editable elements (<input>, <textarea>,
contenteditable elements...)

* It influences the overall design of the property in terms of
inheritance and computed values.

* Mozilla[1] and Tab[2] have expressed at least some interest in
having this value with similar semantics to IE.

Feedback most welcome.

 - Florian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036853
[2] https://lists.w3.org/Archives/Public/www-style/2014Nov/0541.html

Koji Ishii | 28 Apr 08:30 2015

[css-scoping] Remove shadow-piercing and multiple shadow roots, and the change in Order of Appearance

WebApps WG resolved to remove shadow-piercing and multiple shadow roots[1].

As a consequence of this change, two declarations in different trees should always be resolved by the Shadow Tree criteria and should not require calculating Order of Appearance, if I understand correctly.

If I'm missing cases where we still need Order of Appearance in tree of trees, I'd appreciate to be pointed out.

Tab, could you make the change, or PR[2] is on its way if you prefer.