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

[CSSWG] Minutes Tucson F2F 2013-02-04 Monday Afternoon III: Writing Modes, CSS2.1, CSS3 Syntax

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Feb 2013 17:07:53 -0800
Message-ID: <511D8A69.9080508@inkedblade.net>
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
       - 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~


   - 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

   <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
   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
   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
   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 :)


   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

   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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:24 UTC