- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 10 Apr 2013 18:19:00 -0700
- 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