W3C home > Mailing lists > Public > www-style@w3.org > April 2013

[CSSWG] Minutes Telecon 2013-04-10

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 10 Apr 2013 18:19:00 -0700
Message-ID: <51660F84.1010609@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Liam to add proposal for advanced line-breaking to CSS4 Text
   - RESOLVED: Variables move to LC. Inform WebApps, SVG, HTML WGs.
   - RESOLVED: Do not adopt MQ-style invalidation for Selectors
               due to Web-compat concerns.
   - Discussed allowing #123abc to be a valid ID selector, to match
     HTML5. Need to collect data on this.
   - RESOLVED: :nth-child()/etc don't require a parent - they're
               based on siblings.
   - RESOLVED: Changed specificity of :matches()/:not() to the
               specificity of the actual matched selector.
               But see follow-up issue...
               http://lists.w3.org/Archives/Public/www-style/2013Mar/0332.html
   - RESOLVED: Define a new selector that matches element that is
               either completely empty or contains only whitespace.
               Note: Need naming suggestions.
   - RESOLVED: Accept the two profiles of Selectors, with "fast"
               for CSS Selectors and "complete" for Selectors API.

====== Full minutes ======

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   Tantek Çelik
   Bert Bos
   Jim Dovey
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Dael Jackson
   Sylvain Galineau
   Daniel Glamzna
   Rebecca Hauck
   Koji Ishii
   John Jansen
   Brad Kemper
   Philippe Le Hégaret
   Edward O'Connor
   Anton Prowse
   Liam Quin
   Matt Rakow
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Nick Van den Bleeken
   Steve Zilles

Regrets: danielweck, dbaron, florian, leaverou, SimonPieters

<RRSAgent> logging to http://www.w3.org/2013/04/10-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Apr/0197.html
Scribe: TabAtkins

Administrative
--------------

   glazou: Three extra agenda items.
   glazou: First from Tab about Variables, next about text-decor,
           another from Simon Sapin about scientific notation.

Line-Breaking Proposal
----------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html
   liam: I'll just go over general purpose.
   liam: When you add things like hyphenation, etc. you quickly want to
         use a line-breaking algorithm that considers more than one line
         at a time.
   liam: It's more important in print than on the screen, because print
         has "show-through", where you can see a shadow of what's on the
         other side of the sheet.

   liam: This proposal is to let an author/script say "this piece of text
         is going to be interactively edited"...
   liam: I imagine a print processor would set this to "batch" - not edited.
   liam: You care about editted or not because if you insert a word in the
         middle of a paragraph, and you use a multi-line linebreaking algo,
         your text will reflow and your insertion point might move up or
         down a line.
   liam: Some programs handle this by only reflowing when you finish editing,
         but it's ugly in the meantime.  It's a problem with a long history.
   liam: Two parts of this proposal:
   liam: 1) Say your intent, interactive or batch.
   liam: 2) Second, experimentally, say what algorithm to use.

   TabAtkins: Is the "interactive" mode about just editting, or about
              reflowing as well?
   liam: It only matters if the user is in there.
   liam: If the text reflows and you care about a particular line of text,
         that's the same problem you've already got.
   TabAtkins: Okay, next concern - I thought the problem with the TeX
              algorithm was it being too complex/slow.  Has that changed?
   liam: It's slow, yes, but normal text is also really mediocre.  It has
         really bad cases that you need markup to fix, because it's meant
         to be manually checked.
   liam: Commercial products almost all use an n-line algorithm, that's
         only slightly slower than the current linear linebreaking
         (still O(n)).
   liam: With that, you can get quality of line-breaking close to the best
         commercial.

   SimonSapin: Is this related to Adobe's "text balancing" proposal?
   stearns: Don't think so.  You can implement text-balancing in a more
            complex linebreaking algo, but it's not necessary.

   glazou: Do you think this is for both print and screen media.
   liam: Both.
   TabAtkins: Yeah, I know plenty of people who would want good text on
              the screen.

   glazou: I think the next step is an ED.
   liam: I wasn't sure whether the best step was Text 4 or a new draft.
   fantasai: I think it should go in Text 4.
   fantasai: Text 4 needs to be synced up with Text 3 (the text is old,
             because we branched a while ago).
   fantasai: Once it's synced up, we can add things to it.
   liam: When you get to this bit, I'll happily help.
   ACTION fantasai to add Liam's line-breaking proposal to Text 4.
   <trackbot> Created ACTION-553
   ACTION liam to help fantasai add his line-breaking proposal to Text 4.
   <trackbot> Created ACTION-554

image-rendering: smooth
-----------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0750.html
   smfr: Don't think there's anything to say here.
   TabAtkins: Yes, I'm fine with the editting.  Was just on vacation last
              week, so haven't done it yet.

Variables Last Call
-------------------

   TabAtkins: I asked for LC a few weeks ago, but jdaggett wanted a new
              WD first to pull out feedback.  I've done so, and it was
              useful.  Can I go to LC now?
   SimonSapin: I have some questions about how the Syntax works with
               Syntax 3, but I can handle that on the list.  It's technical,
               but I don't think it'll change anything.
   glazou: objections?
   Bert: I don't object, but I don't think we need it...
   RESOLVED: Variables move to LC.

   Bert: We need to decide as a group what other WGs to talk to.
   TabAtkins: WebApps.
   glazou: SVG.
   glazou: HTML?
   TabAtkins: Sure, though most of their connection will be through webapps
              work.
   RESOLVED: Inform WebApps, SVG, and HTML about Variables LC.
   * shepazu wants to talk in-depth with Tab about Variables and Params

Selectors 4
-----------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0187.html
   glazou: Speaking of Selectors, I think some sections of the document
           (time-based pseudos, for example), need a review from the WG.
   fantasai: I brought that up on www-style/at a f2f, but nobody had
             comments.
   glazou: Right.  Everyone, if you have spare cycles, read Selectors 4
           and give comments.

   fantasai: First issue is about adopting MQ-style invalidation.
   fantasai: Currently, any invalid selectors invalidates the entire list.
   fantasai: Alternative is to just drop the selector that's invalid
             (split by commas).
   fantasai: But this seems to be quite web-incompatible, because people
             depend on this behavior.
   sylvaing: How do people depend on this?
   glazou: Right now there are style rules which are fully invalid because
           of one selector, and authors never noticed the wasted rule.
           If you change, it'll start applying and change the page.
   TabAtkins: And there is some history of people using prefixed selectors
              in the selector list as a browser hack, and this would change
              the behavior they're depending on.
   RESOLVED: Do not adopt MQ-style invalidation for Selectors.

   fantasai: Next issue is whether ID selectors should accept all hash
             tokens, or just hash tokens with an ident value.
   fantasai: For example, #1 is a valid hash token, but not a valid id
             selector.
   fantasai: HTML now, I believe, allows IDs that start with a number.
   <tantek> it does

   glazou: Do you think this has compat impact?
   TabAtkins: I suspect this is used much less.
   arronei: Isn't this the same case as the last one?  Groups could be
            invalid currently that would become valid.
   glazou: If HTML now allows non-ident selectors, then this is a needed
           change.
   SimonSapin: Any way to assess the impact of this change?
   [discussion about using Google resources for this]
   hober: It's hard to say without data.
   Rossen: We'd have to run a query and see how many hits we have. Without
           data, we're uncomfortable committing.

   tantek: I don't have any hard data, but I can give you anecdotally...
   tantek: One of the things that happens in mediawiki pages is that
           whatever you use as a heading/subheading gets turned into an id.
   tantek: So if you have a heading start with a number, that's the id.
   tantek: One major complaint I hear is headings that are just numbers.
   tantek: Whether they're getting styled or not, I have no idea.

   TabAtkins: I can confirm that browsers are pretty consistent about
              allowing full hash tokens in Quirks mode, but only restricted
              ident hashes in Standards mode.
   glazou: Two members of the WG are asking for data here.
   ACTION tab to look for data on non-ident hash usage.
   <trackbot> Created ACTION-555
   * sgalineau if this works in quirks the difference makes it harder to
               switch to standard mode...
   <tantek> FYI: regarding ID selectors that start with numbers, we do test
            for the non-support - in the CSS 2.1 test suite:
            http://test.csswg.org/suites/css2.1/20110323/html4/id-selector-005.htm
   <tantek> that's why we have interop among browsers for non-support of
            ID selectors that start with a number.

   <glazou> http://www.w3.org/Style/CSS/Tracker/issues/317
   fantasai: child-index pseudos (:nth-child(), etc.) don't work on
             unparented elements, such as :root.  This makes sense there,
             because there's not much use in having them apply to root,
             but there's also the issue of document fragments.
   fantasai: (the top-level elements in a document fragment won't match
              :nth-child() etc.)
   fantasai: The only argument I've heard against it is that the word
             "child" is in the name, so it should only apply to children.
   glazou: We deal only with elements in CSS.
   [tab explains things wrt DocumentFragment case becoming more common,
    shadow dom, etc]

    fantasai: We wouldn't be having this argument if it were called
              :nth-sibling
    glazou: I would prefer a new pseudoclass.
   <SimonSapin> not 1 new pseudo-classes, 11 of them
   TabAtkins: It's silly and confusing to add new pseudo-class that means
              exactly the same thing except when selecting root or
              DocumentFragment elements
   * fantasai agrees strongly with Tab on this point
   glazou: I don't think it should apply to root.
   TabAtkins: I'm fine with that, if it applies to docfrags and shadow dom
              and the like.
   glazou: I could live with an addition to the shadow DOM spec that says
           shadow roots act like a parent.
   TabAtkins: Then we'd have to add the same thing to DOM for docfrags.
   Tab's proposed spec text:
     The pseudo-classes defined in this section select elements based on
     their index in their parent's list of children (or, if they have no
     parent, by their index in the list of them and their siblings).

   <SimonSapin> can DocumentFragment contain multiple "root" elements?
   <oyvind> yes
   <TabAtkins> no. ^_^
   <SimonSapin> … ?
   <oyvind> well, a documentfragment can have multiple child nodes
   <oyvind> I figured that was what SimonSapin meant :)
   <SimonSapin> oyvind: yes
   <SimonSapin> in that case it makes sense for :nth-child() to apply

   Bert: What does :root match in document fragments?
   TabAtkins: Nothing, I believe.  There's no root element in a docfrag.

   * sgalineau cannot tell if we are in a rathole or a bikeshed
   MINUTE BANKRUPTCY

   Bert: I'm trying to find the similarities between document and docfrag.
   * SimonSapin agrees with Tab
   Bert: If we do this for :nth-child, maybe we should do it for :root too.
   TabAtkins: Nah, no need. :nth-child() is being redefined into just
              based on siblings. :root is still about document roots,
              which docfrags don't have.
   glazou: I'm okay with this change, though I don't like it.
   RESOLVED: :nth-child()/etc don't require a parent - they're based on siblings.
   antonp: Can we have a note saying that the name doesn't make much sense anymore?
   fantasai: Yes.

   Bert: It seems that your addition makes :first-child apply to the root
         element, which wasn't the case before.
   Bert: So should there be text saying that it only applies to docfrags,
         not roots?
   TabAtkins: I don't think that's necessary.  Incidence of :first-child
              selectors that accidentally hit the root should be so low
              as to be effectively zero.
   fantasai: We'll come back with final phrasing so everyone can comment.
   Bert: I'm not comfortable with changing things for existing documents.
         Probably rare for HTML, but there are many other kinds of documents.
   Bert: There's a use-case for fragments, but not for normal documents.
   TabAtkins: I'm fine with discussing on the list whether :root and
              :nth-child/etc should be mutually-exclusive.
   Bert: That's fine.

   <glazou> https://www.w3.org/Style/CSS/Tracker/issues/318
   fantasai: Next issue is about the specificity of :matches() and :not().
   fantasai: Currently the specificity of :matches() is the specificity of
             the most specific selector inside it.
   fantasai: dbaron's proposal was to make it the most specific selector
             that actually matched, so that it truly becomes syntactic
             sugar for the combinatorial-explosion of multiple selectors.
   fantasai: I think there's no reason not to take this, except that it's
             slightly annoying to implement.
   SimonSapin: I brought up that it's not possible to do this when
               converting selectors to XPath.
   SimonSapin: but we should still do it because even in Selectors 3 some
               corner cases can (probably) not be expressed in XPath
   TabAtkins: Yeah, while XPath and Selectors are very similar techs,
              they both have edge-cases that can't be converted.
              It's fine, I think.
   RESOLVED: Changed specificity of :matches()/:not() to the specificity
             of the actual matched selector.

   <glazou> https://www.w3.org/Style/CSS/Tracker/issues/319
   fantasai: Next topic, :empty is pretty useless for most people.
   fantasai: It only selects elements with no nodes, which means that
             whitespace makes it not match, even though that gets collapsed
             away in HTML.
   fantasai: We can redefine :empty to also match if the element is only
             filled with whitespace, or we can make a new pseudoclass for
             it.
   glazou: I recommend the latter.
   fantasai: Is there a use-case for the former?
   Bert: Something with a space isn't empty.
   glazou: I used :empty as it is for something in Gecko.

   <tantek> we have a test for :empty that checks to make sure it is NOT
            applied to an element with only white-space:
            http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-151.html
   <tantek> therefore we have interop on it in current form
   <tantek> so changing it would break all browsers

   fantasai: So what would we name it?
   Bert: :blank?
   fantasai: I thought we might use that for empty inputs...
   <tantek> :space
   <fantasai> tantek, it's potentially empty
   <tantek> space is pretty empty ;)
   <tantek> :visibly-empty
   glazou: What about :almost-empty?
   <plinss> :mostly-empty
   <leif1> :insignificant
   <Rossen> :just-about-empty
   <TabAtkins> :this-element-intentionally-left-blank
   * sgalineau approves of all these as aliases
   <BradK> :good-as-empty
   <tantek> :empty-or-space
   <jdovey> :quiet
   <Rossen> :boring
   <tantek> :silent
   <BradK> :white-space
   szilles: :void
   TabAtkins: Confusing because void refers to what :empty currently means.

   SimonSapin: Would this select elements with other empty children?
   <SimonSapin> <div><div></div></div>
   fantasai: No, only elements that contain nothing or insignificant whitespace.
   glazou: We agree on the selector, but still need to come up with a good name.

   RESOLVED: Define a new selector that matches empty or only whitespace.

   <glazou> https://www.w3.org/Style/CSS/Tracker/issues/320
   fantasai: :matches() was always intended to be able to accept complex
             selectors (with combinators).
   fantasai: Right now the Selectors 4 draft has explicitly excluded them,
             due to performance concerns.
   fantasai: But this confuses everybody, because they want complex selectors,
             and ask for new features.
   fantasai: Also, the performance concerns don't apply to batch processors
             or Selectors API - only to CSS Selectors.
   fantasai: So the idea is to define "fast" and "complete" profiles.
             "fast" is only compound selectors in :matches()/:not(),
             "complete" is everything.
   fantasai: We want to mark this as at-risk.
   fantasai: The alternative is to just include complex selectors and mark
             the whole thing as at-risk.
   fantasai: We just want to find out what implementations actually want
             to do.

   glazou: I have a problem.  It implies that after CR we may have shipped
           impls of either profile, so inconsistency for the web.
   glazou: I understand you have the two profiles for Selectors API.
   glazou: I'd prefer that the fast profile be explicitly limited to CSS
           Selectors, and complete be for everything.  Then we can decide
           to open up the profiles later.
   glazou doesn't want individual implementations deciding whether to
          implement "complete" profile for CSS.
   SimonSapin: I'm concerned that the same impl could match different
               profiles based on the use (print vs live, etc.)
   SimonSapin: Would prefer that we restrict selectors on CSS for all
               types of implementations.
   fantasai: I'm fine with this.
   fantasai: I just want to reduce confusion in the spec.

   plinss: If we later allow browser to implement the complete profile,
           there will still be a transitional state, so I'm not sure what
           we buy here.
   fantasai: If everyone's ready for it, there will be a short transition
             period, as opposed to the current undefined transition.
   glazou: What if we just mark the complete profile as being informative,
           with it being defined normatively in the future?
   TabAtkins: I'm opposed to that, because I want Selectors API to pick it up.
   glazou: I'm okay with that.
   RESOLVED: Accept the two profiles of Selectors, with "fast" for CSS
             Selectors and "complete" for Selectors API.
Received on Thursday, 11 April 2013 01:19:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 11 April 2013 01:19:29 UTC