- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2013 17:07:53 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Writing Modes
-------------
- RESOLVED: Add 'ascii-digits' back in as 'digits' to text-combine-horizontal
- Tried to come up with a better name than 'text-combine-horizontal'. Ideas
include:
- text-horizontal (but 'text-horizontal: none' is nonsensical)
- horizontal-in-vertical
- force-horizontal
- text-force-horizontal
- text-縦中横
- text-inline
Further comments and suggestions are welcome~
CSS2.1
------
- RESOLVED: Develop text for CSS2.1 PER as open editor's draft (while
continuing to maintain errata). Publish PER when we're
done & have updated implementation report
CSS3 Syntax
-----------
- Reviewed current list of differences from CSS2.1 syntax
- RESOLVED: Add tokens for all the multi-character attribute selector
operators to css3-syntax
====== Full minutes below ======
Writing Modes
-------------
http://dev.w3.org/csswg/css3-writing-modes/#text-combine-horizontal
<dbaron> should we wait for jdaggett?
<jdaggett> how about tomorrow for writing modes?
<jdaggett> i haven't looked over the changes in that section yet
Rossen gives a history of various values for text-combine-horizontal
http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
Rossen: Lot of feature creep for not much benefit.
Rossen: most of the content that requires this has 2 or at most 4
ASCII digits
Rossen: That's 90% use case
<jdaggett> oh well, guess i'll just review the discussion and reopen
issues if need be
Rossen: Decision was to retract back on adding explicit markup around
horizontal bits in order to style individually
Rossen: Which seems like underkill
Rossen: Proposal is to go back to what is that we really want to
accomplish here.
Rossen: Original idea was pretty good, want to have automatic display
of horizontal-in-vertical
Rossen: If most widely used cases is 2-4 digit ascii numbers, then
let's do that, have that be possible
Rossen: So add back the 'ascii-digits' value.
<jdaggett> text-combine-horizontal: none | all | digits
<jdaggett> covers 99% of the use cases
Rossen: Let's specify ascii digits only
Rossen: as 'digits'
Rossen: If we want more, then add 'digits-extended' or something.
Rossen: That's the digits value.
Rossen: Then the discussion went on to well, we also hate the name it's
quite verbose
Rossen: text-combine has some historical bad connotations
<jdaggett> i agree
Rossen: so apparently we should stay away from that
<jdaggett> exactly what Rossen is saying...
Rossen: Our proposal was instead of text-combine-horizontal, just go
with text-horizontal
Rossen: When text is horizontal, it has no effect
Rossen: when its vertical, it keeps the text horizontal
dbaron: text-horizontal: none; makes no sense to me
dbaron: Maybe use 'normal', or 'auto', but 'text-horizontal: none'
sounds like asking for vertical text....
* TabAtkins thinks we should avoid using 'auto' too early in a property's
lifecycle.
glenn: I like the 'combine' in the property name.
<jdaggett> or text-inline?
* sylvaing detects a match for the :bikeshedding state
* stearns why not tate-chuu-yoko? It's got hyphens in the name and everything
Glenn: 'all' value says that if there's an element boundary between,
reverts to none. Why does it prevent combination if I want
to color one of the characters?
szilles: That's a separate issue.
fantasai: That was for implementation simplicity.
Rossen: Let's go issue by issue
szilles: If I put a block in, and make it switch direction, then I can
do anything I want
szilles: There's another mechanism that allows you to do that.
szilles: This is only for one simple thing, therefore well-defined in
simple case.
fantasai: Setting writing-mode: horizontal-tb; would get you an inline
block that does whatever you want
szilles: This also compresses whatever you put in there to fit within
an em
Glenn: Does it allow overlap of advancement?
szilles: Believe that's UA-defined
<SimonSapin> nobody asked for vertical digits in horizontal text?
<sylvaing> SimonSapin, use-case?
<SimonSapin> sylvaing, messing with spec writers
Rossen: Going back to first issue, reintroducing 'digits' value. Does
anyone have an objection to that?
Bert: Why not use a 'display' value?
fantasai: Wouldn't be able to do the automatic processing, which is
important.
http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
szilles: Seems like nobody's opposed to adding tat value back in,
just change the name so that ascii is implied
RESOLVED: Add 'ascii-digits' back in as 'digits' to text-combine-horizontal
<jdaggett> good
Rossen explains what this value does to Bert
Glenn: Why limit to ASCII digits?
<jdaggett> because that's the use case
Rossen: This is the 90% use case, and it's simple
<jdaggett> arabic digits == no use case!!!!!!!!!!!!!!
<jdaggett> ditto for any other sort of digit you want to find in Unicode
* fantasai thinks roman numeral digits would have a use case in Japanese
<jdaggett> actually it's the 99.999999999999999999999999% use case
Glenn wants all Nd characters from Unicode
szilles: Don't want all digits b/c definitely don't want fullwidth digits
to combine
<jdaggett> Nd characters == no matching use case
<jdaggett> the only real use case outside of digits is 1.3
<jdaggett> but authors can use 'all' for that
Glenn wants naming the other way around, with 'digits' being generic
and a more specific name for the ASCII digits thing.
<jdaggett> ascii-digits == silly name
szilles: I'm neutral on the name. In the end I don't think it matters.
Glenn: Do we elsewhere use the term digits when we specify that it refers
to Unicode definition of digits?
<jdaggett> the value name is contextual
<jdaggett> in this case digits means ascii digits
<jdaggett> keep it simple please...
fantasai: I think the closest thing we have is font-variant-numeric,
which uses -numeric and -nums
koji: CSS Speech has speak-as: digits
szilles: Is digits a technical term in the Unicode spec?
<fantasai> The Nd category is called "Number, Decimal Digit"
* fantasai actually wonders why we use -nums instead of -digits
* sylvaing Because Unicode and/or OpenType call them numerals, among other things?
<jdaggett> btw, -nums was used partly because we had -caps already
<jdaggett> and this has been debated on www-style before
Glenn concedes on digits
Bert: Why 'all'?
Rossen: 'digits' implies auto-discovery
Rosen: 'all' implies you've found your content, and you transform it
<jdaggett> because you want to deal with cases like '1.3'
<jdaggett> which there are examples of in existing content
Rossen: So, text-horizontal?
TabAtkins: Kinda like having the 'combine' in the name
fantasai: One problem I have with 'text-combine-horizontal' is that
we have 'glyph-orientation-horizontal'
fantasai: The first takes effect only in vertical text, the second
takes effect only in horizontal text
<fantasai> also it's long....
Rossen: We can leave this open
Rossen: Call it 'horizontal-in-vertical'
<jdaggett> ewwww
<SimonSapin> yay for 'text-combine'! works for vertical stacks of digits
in horizontal text
plinss suggests using the ideographic characters
TabAtkins protests this violates earlier decision not to add non-ASCII
property names
fantasai points out it is not bicameral
[the jokes get worse and worse]
<jdaggett> text-縦中横はどう？
fantasai: So we have some open naming issues. Suggest we don't solve
any of them right now.
szilles: 'force-horizontal'
<jdaggett> that works too
plinss: could also do text-force-horizontal
<dbaron> (but a bunch of people did like force-horizontal)
<jdaggett> or text-inline...
plinss: Next?
Topic: before/after logical directions
<jdaggett> hmmm, logical direction discussions for a spec we want to
go to LC?
[above/below is an available pair]
[someone mentions they're kindof oriented up/down, but so are over/under]
<dbaron> There was also a brief joke about using 上/下.
fantasai: at least people are more likely to guess correctly which of
above/below start/end is in which direction
szilles: I think it's better to stay with before/after until we come up
with clearly better terms, but I admit to being biased.
fantasai: above/below do clearly map to those ideographic characters :)
CSS2.1
------
fantasai: Status of errata? Are they in sync with resolutions?
fantasai: How do we get an up-to-date draft somewhere public?
Bert: Make a WD. Or PER?
dbaron: PER is like LC and PR at the same time
dbaron: Get LC comments, and a simultaneous AC vote
Bert: Probably want WD then
fantasai: We're just going to confuse everyone by publishing it as WD
dbaron: Think we should do an Editor's Draft, and at some point go to PER
Bert: That's confusing, having a non-official WD and still want comments
on it.
dbaron: It may be that most of the rest of the world doesn't know that
PER is like LC
Discussing process of updating the 2.1 REC
dbaron: I think we should have a public editor's draft before PER
dbaron: Would rather not go through rest of the process
dbaron: Don't want LC/CR again for example
dbaron: Publishing WD would be a confusing signal
[not minuting this]
szilles: Prior draft to PER would be the REC itself
szilles: Only if the PER is rejected would it have to go back to WD.
szilles: Requirements are you describe in the PER what has changed since
REC, but errata already do that.
szilles: Fact that we work in public is just a side benefit
szilles: Best I can determine, it's not inventing new process.
Bert: The reason we're publishing an editor's draft is to help people
so that they don't have to look at the errata.
Bert: But the editor's draft is not WG-approved. How are we helping?
tantek: transparency
fantasai: You can double check the editor by double-checking the errata
[more process discussion]
szilles: Best plan I've heard so far is that we begin to develop the
text for the PER as an open editor's draft, and that when we
get it to point where we think we're happy with it, and we
have implementation report, we request a PER.
szilles: That means having some way of writing an implementation report.
fantasai: That makes sense. /TR is up-to-date because it has errata,
editor's draft is up-to-date b/c editor's draft. As long as
we keep the errata and the editor's draft in sync, everything's
in sync
fantasai: As long as Bert checks things into both places, it's good
RESOLVED: Follow szilles' plan. Bert takes responsibility for keeping
things in sync.
Bert: Where do we put the editor's draft?
Bert: Annoyance with Mercurial is that making edits to any module requires
merging/updating all others.
[Bert describes annoyances of working with mercurial vs. cvs]
* tantek is relieved he's not the only one who suffers with a lot of
friction with our editing / source control tools.
dbaron: You can commit just a directory, rather than all changes to the repo
Bert: I can't do a push unless everything has been committed
plinss offers to help Bert offline
fantasai: So goal is that it shows up on dev.w3.org and how that happens
it TBD
ACTION Bert: publish editor's draft of CSS2.1
<trackbot> Created ACTION-531
CSS3 Syntax changes from 2.1
----------------------------
SimonSapin: Changes to syntax, should we backport?
fantasai: If there are changes in behavior, we should keep the two specs in sync
<SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-tokenizer
<SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
dbaron: I disagree with the change to DASHMATCH and INCLUDES
dbaron: I want to see ... because that's hard.
SimonSapin: DASHMATCH is important for disambiguation with namespace
dbaron: You need DASHMATCH to avoid two-token lookahead
SimonSapin: I had 3 in my implementation
dbaron: With DASHMATCH, I believe nothing in CSS needs more than 1 token
of lookahead in the parser
dbaron: If you implement attribute matching without DASHMATCH and
namespaces, you'll need 2-token lookahead
dbaron: If you're parsing attribute selector and you see |, you can't
tell whether namespace or |= without 2-token lookahead
TabAtkins: What are your opinions on other match tokens. Should we just
have DASHMATCH?
SimonSapin: Selectors 3 added a few attribute selector operators
SimonSapin: Tokenizer only had tokenizer for a few
dbaron: Thought change was implicit in 3
dbaron: Gecko adds tokens for all the match types in Selectors
TabAtkins: Ok, that seems fine
RESOLVED: add tokens for all the multi-character attribute selector
operators to css3-syntax
SimonSapin: The core grammar is written that it has a promise not to change
SimonSapin: But if we're fine with changing sometimes, then ok
TabAtkins: We added scinot, so that's a change
TabAtkins: Agreed to pull plus/minus signs into NUMBER token
dbaron: Wouldn't want to backport plus/minus thing to 2.1...
TabAtkins: OK, revert #1 and add additional tokens for Selectors
TabAtkins: I need to do testing for #2. There's a thread about it
TabAtkins: Only matches WebKit's parsing, which is stupid.
TabAtkins: I made a lot of decisions based on WebKit and only realized
afterward that we do stupid things.
dbaron: All other browsers are more internally consistent, and also
more consistent with spec
dbaron: We've only changed this 3-4 times in the past 3-4 years. :)
Trying to find out what our code does this week.
TabAtkins: Afaict, we haven't gotten any compat bugs on it.
TabAtkins: May not be important that we do something different than
everyone else.
TabAtkins: 3 and 5 were decided by WG
TabAtkins: #4 is irrelevant for CSS, just lets you use the same parser
for SVG.
fantasai: The NUMBER thing looks inconsistent across our specs.
TabAtkins: I'll go through all our specs and check that they're
consistent once we're ready to publish this.
TabAtkins: On the parser side, changes are more minor.
TabAtkins: Grammar didn't allow certain things before, now show up
[] blocks, () blocks and functions can now contain {} blocks, at-keywords
or semicolons
http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
Discussion of @page parsing
dbaron: the "Selectors can now contain semicolons " should say it's talking
about only selectors for style rules and not @page selectors
TabAtkins: no, because Selectors in the terms of the syntax spec is only
selectors in style rules; @page selectors in the terms of the
syntax spec are an @-rule prelude
dbaron: ah, that's what I don't like about the multi-level stuff in the
syntax spec
TabAtkins: you don't have to implement it as multi-level
dbaron: ... until you make a mistake
dbaron: Maybe the term for the thing thing that the parser parses to
go where a selector goes shouldn't be "selector"?
TabAtkins: maybe "style rule prelude"?
[discussion about parsing and how to write and specify parsers]
Bert: now that selectors can contain semicolons and @-keywords...
the whole of an @-page rule ... ...
Tab: @-rules are either rule-filled or declaration-filled. Either of
them can have @-rules in them, but nothing can contain both
declarations and style rules.
<dbaron> I'd like to have some sort of a conclusion about the terminology
in css3-syntax.
<dbaron> but it seems like we're gradually closing the meeting
Meeting closed.
Received on Friday, 15 February 2013 01:08:20 UTC