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

[CSSWG] Minutes Tucson F2F 2013-02-06 Wed AM I: Variables II, Placeholder Styling II, Regions, Conditional Rules

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 15 Feb 2013 15:15:04 -0800
Message-ID: <511EC178.9050202@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Spec Processing
---------------

   - Discussed making spec processor public / offline

Variables II
------------

   - RESOLVED: Can't put unmatched brackets, braces, parens in variables
               (unless escaped) [i.e. no change]
   - RESOLVED: No badstring or badurl in variables [i.e. no change]
   - RESOLVED: Accept CDO/CDC at top level in variables
                 http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html

Placeholder Styling
-------------------

   - RESOLVED: :placeholder-shown pseudo-class & ::placeholder pseudo-element adopted

Regions Update
--------------

   - Regions polyfill (limited functionality, limited perf) available for experimentation:
       http://adobe-webplatform.github.com/css-regions-polyfill/

   - Discussed use of Web Components for region-based templating and
     linking them to the document via CSS.

Conditional Rules
-----------------

   - RESOLVED: @supports is not affected by limitations imposed by user prefs
               or system limitations

   - RESOLVED: Not adding @supports all.

   - Reviewed some other issues in DoC.

====== Full minutes below ======

Spec Processing Machinery
-------------------------
Scribe: dbaron

   jdaggett: It would be helpful to gave the module preprocessor scripts
             on the dev.w3.org public tree rather than the css3-src
             member-only CVS tree so that we can use them locally from
             that tree.
   jdaggett: Bert, would you mind that?
   Bert: I don't mind, but it's a lot of work.
   [discussion]
   Peter: Anolis is also more self-contained.
   ACTION Bert (with help from jdaggett) to move the css3 module preprocessor
               scripts from the member-only css3-src tree into the dev.w3.org
               hg public tree due 2013-06-01
   <trackbot> Created ACTION-537

Variables (continued)
---------------------
Scribe: fantasai

   dbaron: We had some discussion on list about what exactly should and
           shouldn't be allow in variables.
   dbaron: Simple change I would like to make
   dbaron: Current rules have quirk that CDO/CDC are only allowed if they're
           inside braces, but not at top level
   dbaron: Would like to change this.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html
   dbaron: Some other discussion about rules
   dbaron: Remaining discussion was wrt allowing unmatched constructs
   dbaron: I'm queasy about that
   fantasai: Would break forward-compatible parsing.
   TabAtkins: Only proposing to add closing brackets
   dbaron: I meant six things
   dbaron: Opening brackets, braces, parens, baduri, badstring, badcomment
   dbaron: These consume to end of file
   dbaron: except for baduri and badstring
   fantasai: I don't think allowing closing brackets while preventing opening
             brackets is helpful to anyone. Just escape both of them, it's
             consistent and predictable
   dbaron: [gives example of where, a year ago, we could have allowed
            closing parens, but then now that would prevent use of such
            rules in @supports]
   RESOLVED: Can't put unmatched brackets, braces, parens in variables
             (unless escaped)
   RESOLVED: Accept CDO/CDC at top level in variables
             http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html
   dbaron: baduri is very much like an unmatched opening paren
   RESOLVED: No badstring in variables
   dbaron: I'm ok with accepting badurl, but would like to review the text
           before going to LC
   plinss: I'm a little uncomfortable accepting badurl...
   TabAtkins: It's like a function token
   plinss: It takes other things inside that though
   plinss: Inside a URL token, can't you have unmatched square brackets?
   dbaron: Yes
   plinss: That's dangerous
   plinss: I don't think you're gaining a whole lot by accepting badurl
   plinss: The URL token is a realy odd weird piece of CSS parsing
   plinss: I suspect we'd be opening up a danger zone and break something
           down the road
   antasai: I think it's safer not to accept badurl, and it's a very weak
            use case.
   plinss: I'm not strongly against it, but I'd have to be convinced it's
           ok, and I'm not convinced it's ok
   RESOLVED: badurl is not allowed in variables
   <dbaron> (so all the resolutions here except for the CDO/CDC change are
             no-change resolutions)

Placeholder Styling Part III
----------------------------

   glazou: discussion limited to 20 minutes

   TabAtkins: My proposal is to do the placeholder pseudo-class and
              fill-opacity
   TabAtkins: which fantasai called her crazy proposal
   TabAtkins: I know dbaron had an objection to fill-opacity, didn't get
              into it
   dbaron: I'm not objecting to doing it, objecting to making decent
           placeholder styling depend on that
   tantek: Would fill-opacity affect performance of existing pages using
           placeholder?
   TabAtkins: No. You just multiply color's alpha by fill-opacity and use
              that. Very simple.
   * stearns thinks he agrees with dbaron - fill-opacity would be good
             to do, but seems separate from the issue of styling placeholder
             state versus placeholder value content
   smfr: A little odd to do fill-opacity without fill

   dbaron: My concern is web-compat implications
   dbaron: Maybe people are using it and expecting it to have no effect
           outside of SVG
   TabAtkins: Same problem with other SVG properties we import
   tantek: We could add fill-opacity, leave placeholder issue open
   dbaron: Point is I want placeholder issue resolved in a timeframe
           that's faster than resolving fill-opacity
   dbaron: I'm fine with pseudo-class + pseudo-element

   Tab: I think the only problem there was that we couldn't decide on names.
   [Tab sets up a possibility table on the whiteboard]
   szilles: Could you describe what each thing is?
   TabAtkins: ::placeholder is a box immediately containing the placeholder
              text
   TabAtkins: :placeholder is a pseudo-class that matches the input element
              when the placeholder is showing
   TabAtkins writes various options on the whiteboard

   Pseudo-class:
     :placeholder
     :has-placeholder
     :showing-placeholder
     :placeholder-showing
     :placeholding

   Pseudo-element:
     ::placeholder
     ::placeholder-text
     ::placeholder-content
     ::placeholder-value

   <stearns> ::value?
   Tantek: eliminated ::value because of sylvaing's use case about fading
           out the placeholder while typing
   <stearns> ok
   ?: eliminate ::placeholder-text because of Bert's objection that it might
      not be text

   fantasai: Authors might be more likely to go for the one that's just
             called "placeholder"
   fantasai: Also if one author uses pseudo-class and the other uses
             pseudo-element, cascading rules don't apply
   dbaron: That same confusion happens with nested elements.
   Tantek: agree with dbaron; it's an existing style sheet cross-organizational
           problem

   * stearns has a preference for ::placeholder and some other name for the
             pseudo-class, as ::placeholder matches the HTML attribute
   * fantasai thinks she agrees with stearns, but isn't sure what to call
              the other thing
   <stearns> :showing-placeholder makes the most sense to me
   <dbaron> I'm in favor of ::placeholder and :showing-placeholder as well.
   Bert: I agree with fantasai, I think authors will think of the two as
         being mostly the same thing
   * fantasai agrees with dbaron and stearns
   Tab and Peter want :placeholder and either ::placeholder-{content,value}
   * glazou agrees with dbaron and stearns and fantasai

   tantek: Prever :has because it's shorter
   smfr: Problem with has is that it might mean "has a placeholder attribute"
   * SimonSapin agrees on ::placeholder and ( :showing-placeholder or :placeholder-showing )
   <dbaron> :placeholder-shown ?
   <Bert>  :waiting, :pre-fill, :hinted, :prompt
   tantek: :placeholder-shows
   plinss: :placeholder-active
   plinss: :placeholder-visible
   <dbaron> loooking at HTML5 spec's terminology leads to
            :placeholder-presented, which nobody likes
   Tantek: :shows-placeholder ?

   Straw Poll
   A :placeholder-shows
   B :placeholder-active
   C :placeholder-visible
   D :shows-placeholder
   E :placeholder-shown
   glazou: E
   jdaggett: abstain
   SimonSapin: E
   dbaron: C
   glenn: abstain
   koji: abstain
   fantasai: abstain
   smfr: C
   Rossen: abstrain
   Tantek: D
   2 more abstains
   [The Japanese Delegation abstains]
   Steve: weak E
   Bert: abstain
   Peter: Still prefer :placeholder and ::something-more
   plinss: votes for the write-in candidate
   Tab: C, though I prefer plinss's write-in-candidate
   Conclusion: E vs. C

   glazou: I think from international audience, I think best is :placeholder-shown
   glazou: It's understandable. Does not confuse with visibility property
   <stearns> C might be better than E - visible may be in more people's
             vocabularies than shown
   Tab: any objections to E?
   RESOLVED: :placeholder-shown & ::placeholder adopted

Regions Update
--------------

   szilles: Many, but not all, were at meetup last night
   szilles: Main new thing is that there's a polyfill out there
   szilles: Runs on any modern browser
   szilles: a) not function complete, and b) perf-challenged
   szilles: But allows experimenting with the concepts
   szilles: Example in the appendix now splits out definition of area in
            which regions are defined into separate file, as a Web Component,
            using shadow dom
   szilles: Both Bert and Håkon replied that this deals with their objection.
   szilles: That's the essence of what I wanted to say.
   szilles: questions or concerns?

   glazou: We don't have no mechanism for easy/fast prototyping of CSS features
   glazou: Long ago a proposal for having selectors that map to JS boolean
           method
   glazou: We need to think about a way for prototyping CSS features via JS
   glazou: Would allow larger experiments and tests
   <TabAtkins> See my recent blog post over this exact topic:
               http://www.xanthir.com/b4N80
   glazou: Web community needs it, we could also use ourselves, something
           to think about for the future
   <TabAtkins> +1
   <stearns> see also: http://www.w3.org/community/nextweb/
   <SteveZ> URL for Regions Polyfill:
            http://adobe-webplatform.github.com/css-regions-polyfill/

   Bert: The web component example refers to the web components in the HTML,
         not from the CSS
   Bert: So you still can't do this from CSS
   szilles: I thought we had some kind of include
   Bert: Yes, that's what we discussed
   Bert: But it appears not to be there
   Bert: So you still can't reuse the style sheet
   Bert: you need to change the HTML file if you want to change style
   Bert: There is no other way, apparently
   szilles: Ok, I will take that comment back
   szilles: If there was a way of including a template description via
            stylesheet instead of via HTML
   <stearns> there is a way using decorators, but that's not as far along
             as templates
   <stearns> I showed a decorator example on the wiki page
   fantasai: The requirement here is that you can change whether or not
             regions are used, or what template is used, without touching
             the markup
   fantasai: And the comment from Bert is that this example does not meet
             that requirement
   tantek: To put another way, you can make that decision via media queries
   tantek: I'd say what fantasai says, except s/markup/content/

   tantek: I'd also say, our examples should be exemplary, not bad examples,
           but show best practice
   tantek: Path of sending different markup is a bad path in general.
           Causes problems across browsers, esp. non-majority browsers,
           across devices
   tantek: Anything we can do to discourage sending different markup is a
           good thing
   <stearns> web components are bad practice?

   glazou: Anything else on Regions?
   Bert: Assuming we do this Web Components, where should it be defined
         that you can include Web Components?
   Bert: Where is the syntax defined for including the Web Components?
   TabAtkins: In the Web Components spec
   Bert: But that doesn't define a CSS syntax
   Bert: If you include a style sheet, that style sheet has to in turn
         somehow include a Web Component
   TabAtkins: Use <link>
   Bert: That doesn't work for XML
   szilles: I have some ideas
   szilles: Need to think about it
   ACTION Steve: figure out how to link web components templates for using
                 regions via CSS
   <trackbot> Created ACTION-538

Conditional Rules
-----------------

   <dbaron> http://dev.w3.org/csswg/css3-conditional/doc-20121213-LCWD.txt
   dbaron: First issue is editorial, improving examples
   2nd issue solved already:
     http://lists.w3.org/Archives/Public/www-style/2012Dec/0277.html
     http://lists.w3.org/Archives/Public/www-style/2012Dec/0330.html

   3rd issue: http://lists.w3.org/Archives/Public/www-style/2013Jan/0070.html
   "What does @supports return when the OS prevents the support?"
   dbaron: Basically, this is things like "what happens if the user has a
           browser pref to ignore colors, or what happens if it's Windows
           high-contrast mode, should the UA say the color property is not
           supported?"
   dbaron: My inclination is to say not pay attention to that
   dbaron: These can be considered UA stylesheet rules
   dbaron: In some cases, might not want to expose this information
   jdaggett: I think this is a very slippery slope
   dbaron: In which direction?
   jdaggett: If you're defining this based on some sort of relatively
             subjective definition of whether this is supported or not,
             will be very ambiguous. Other things will come upw that
             will cause us to churn
   dbaron: So in favor of saying that it does not affected by this stuff
   jdaggett: yes
   jdaggett: Should be very cut and dry
   plinss: I agree with that
   plinss: Also, those sorts of things, if they're going to be exposed,
           should be via media queries
   plinss: You don't say you don't support 'color' if you're on a monochrome
           display
   SimonSapin: @supports should match whether declarations are handled as
               invalid
   dbaron: That's exactly what I was going to say.
   dbaron: Sounds like we're all in favor of saying that it's not affected
           by things like UA preferences
   dbaron: Add text to the spec saying that
   RESOLVED: @supports is not affected by limitations imposed by user prefs
             or system limitations

   4th issue
   http://lists.w3.org/Archives/Public/www-style/2013Jan/0436.html
   dbaron: Replied to reject [explains rationale in message]
   http://lists.w3.org/Archives/Public/www-style/2013Jan/0442.html
   fantasai: I agree with your rationale
   fantasai: If we want to go in that direction, should add some syntax
             for flagging individual lines as required.
   fantasai: But not doing that right now anyway.
   RESOLVED: Not adding @supports all.

   5th issue
   dbaron: WebApps posted API issues
   dbaron: Made some edits to clarify
   dbaron: One thing I need to figure out, need to test what implementations do
   dbaron: Haven't had a chance to do that yet
   fantasai: Can anyone else help with that?
   dbaron: It's error handling for insertRule
   dbaron: Same question exists for the style sheet object
   dbaron: We should come back on this one

   6th issue should come back on
   dbaron: It's a long message sent not too long before LC
   dbaron: Rewrote a bunch of stuff, have to figure out whether addressed
           or not
   dbaron: Don't think we're quite ready for CR
   dbaron: But maybe next telecon

   [discussion of scheduling next telecon]
   ppl travelling next week, so next call is the 20th

<br type=coffee>
Received on Friday, 15 February 2013 23:15:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT