- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 15 Feb 2013 15:15:04 -0800
- 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 UTC