[CSSWG] Minutes and Resolutions Seattle F2F 2011-07-24 PM: F2Fs, Selectors 4, CSS3 Text, Serialization, Testing

F2F Scheduling

   Discussed possible dates and places for meetings next year. Current top candidates
   are Paris in January, Bucharest in May, San Diego in August, TPAC in November.

Selectors 4

   - Reviewed new features:
       - local hyperlink pseudo-class
       - any hyperlink pseudo-class
       - :matches() and :not() extensions to allow OR operations
       - column selectors
       - :dir()
       - case-insensitive attribute matching

   - Discussed new terminology, various editorial suggestions

   - Discussed scoping, Selectors 4 vs. Pseudo-Elements split, whether to publish
     FPWD now or after Selectors 3 REC, and how to make people less confused about
     what Selectors 4 is and why it exists.

CSS3 Text

   - Discussed use cases for values of 'text-space-collapse'.

   - RESOLVED: Add <length> to 'tab-size' property, mark at-risk.

   - RESOLVED: Drop hyphenate-resource. It can be put back if there's more implementer
               interest and a better spec.

   - RESOLVED: text-decoration-line follows pattern of
                 none | [underline | no-underline | reset-underline] | ...
               exact keywords TBD.

   - RESOLUTION: Rename word-wrap to overflow-wrap, add a note that browsers
               may accept word-wrap.

   - RESOLVED: No change to current line-break property, add note about future
             extensions for more precise control.

CSSOM Serialization

   - Discussed general principles of CSS serialization

   - Discussed how to make progress on defining serialization given there's no
     base spec yet and each property needs property-specific info.


   - Media Queries is stuck in CR because we still lack passes in the test suite.

   - Discussion of testing Transitions and Animations

   - Peter Linss is actively working on a tracking system for tests and test suite errors.

====== full minutes below ======

Scheduling of upcoming F2F meetings
ScribeNick: dbaron

   Peter: Let's try to get some concrete dates
   Peter: Daniel proposed last week of January or first week of February
   Daniel: Week of Jan 30 - Feb 3
   Peter: Let's figure out dates first, then places
   SteveZ: Need to avoid MLK weekend and President's day weekend in the US,
           if families with children.
   dbaron: SXSW Interactive is March 9-13
   Molly: consider weather for Jan/Feb
   <tantek> http://wiki.csswg.org/planning/2012
   Daniel: La ... is a meeting space in the center of paris with a lot of
           meeting rooms, W3C has connections.
   Daniel: near Grand Boulevard metro station
   <tantek> Please add dates to avoid meetings on this wiki page:
   <tantek> (I've added SXSW)
   Peter: I'm proposing 4 meetings next year, including TPAC
   David: If we spaced evenly...
   Daniel: Late July doesn't work for me next year
   <tantek> updated: http://wiki.csswg.org/planning/2012
   Daniel: end of April doesn't work for me; beginning of May does
   Florian: Golden week in Japan -- ok with me, what about others?
   Peter: so, First week of may?
   Koji: First week of May not very good for Japan, though second week is ok
   Peter: Week of may 7-11?
   WWW2012 is April 16-20 in Lyon
   Steve: I might be able to figure out AC meeting dates tomorrow.
   Peter: Let's get a stake in the ground.
   Peter: first week of August... July 30-August 3?
   Steve: might not work for me
   Steve: first 2 weeks in August bad for me
   Peter: August 13-17?
   Peter: ok, august 13-17
   Peter: ok, target is weeks of Jan 30-Feb 3, May 7-11, Aug 13-17
   ... plus TPAC, whenever it is
   Peter: locations?
   Peter: TPAC likely in Europe
   <bradk> Hawaii is nice
   Daniel: could do Paris in Febuary
   Peter: I can do any in San Diego
   Peter: But then we're 3 in a row on the US west coast.
   Kimberly: I could do Philadelphia, preferably May
   Bucharest, Adobe
   Arno: Could do Hamburg as well if it makes a difference...
   [fast discussion of date/place combinations]
   Daniel: don't want 3 in a row in the US
   Peter: so, Paris in January
   Peter: ok, Bucharest in May, and San Diego in August
   Peter: so we have something laid out, will narrow down later so people
          can book flights
   <tantek> for Paris - would prefer more toward end of January than into
   <tantek> IxDA is Feb 1-4
   Steve: Got reply -- AC likely Japan or Sophia in May, TPAC probably Lyon
          in October/November 2012.

<anne> tantek, what is that wiki page we have on HTML issues?
<anne> tantek, I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13346 on the :ltr and :rtl pseudo-classes needing to be 
changed to use :dir
<tantek> anne - thanks! http://wiki.csswg.org/spec/reviews/html5

Selectors 4

   <fantasai> http://dev.w3.org/csswg/selectors4/
   fantasai: I've done a little cleanup on the draft.  I wanted people to
             know what's in here before FPWD.
   fantasai: Started with a copy of selectors 3, minus the pseudo elements
             which I think should be in a separate module.
   fantasai: I added :links-here and :current
   glazou: :links-here used to be :local
   fantasai: oh, I like that better
   Daniel: or, more explicit, :local-link
   many: :local-link
   <anne> :local-link is bad
   <anne> is there :local-visited?
   fantasai: two forms, :local-link says url points to the page we have now,
             and the other form takes an integer argument says how many
             levels of depth in the URL you match against
   <glazou> anne :local-link:visited ?
   fantasai: a level of 0 selects any link to the same domain, 1 any link to
             in the same path segment
   fantasai: allows easier styling of navigation on Web sites
   peter: I could also see a use for levels of subdomains
   fantasai: negatives?
   Tantek: subdomains are an anti-pattern; don't use them
   peter: they're useful

   glazou: Two questions: :not() extended from single simple selector to chain
   glazou: what do browsers think?
   glazou: hyatt wanted to extend
   dbaron: fine with it
   florian: Happy with :matches(), extension to :not is similar

   glazou: Authors want column selector.
   <fantasai> http://dev.w3.org/csswg/selectors4/#table-pseudos
   fantasai: Have :nth-column(an+b), :nth-last-column(an+b), and
             :column(selector) in the spec
   glazou: columns don't really exist -- it's just the count of cells
           counting colspans
   TabAtkins: the table has columns, though
   TabAtkins: we're talking about conceptual columns, not column elements
   anne: And HTML needs to say how they apply to tables.
   fantasai: I think we could clarify the wording at the top of the section
             (Grid-Structural Selectors)
   <bradk> I had some ideas from 2007:
   Tantek: Did you document the scope of the spec as not including
   fantasai: yes

   anne: How about :any-link, for :link or :visited.  Every browser has that
         as proprietary (Gecko, WebKit, Opera).

   glazou: We need to write a spec for scoped style sheets.
   glazou: Do scoped style sheets add to specificity?

   dbaron: I'm not ok with another set of selectors terminology.
   dbaron: I'm ok with any of the previous sets.
   dbaron: I guess I'm ok with it if you're not *changing* terms.

   glazou: Do we need in selectors4 all that will be unchanged?
   fantasai: yes, definitions need improvement

   anne: case insensitive attribute matching
   anne: HTML now makes data model consistent between HTML and XHTML
   fantasai: Can you post to www-style?
   glazou: have to extend attribute selectors
   anne: It's an edge case -- most authors will just write in lowercase
   glazou: If you want to highlight based on a word in the title
   dbaron: I think you're making up a use case here.
   glazou: So I want strings rather than just tokens
   fantasai: What if unquoted things were case-insensitive?
   dbaron: That's a pretty big change.
   peter: Safer to have new syntax that says it's case-insensitive.
   peter: quotes with an i after the quotes -- just an identifier after
          the quotes

   fantasai: added :any-link
   dbaron: horrible name... probably my fault... can we find a better one?
   fantasai: :hyperlink?
   tantek: :hlink?

   glazou: document contains :dir(); HTML5 contains :ltr and :rtl
   anne: already raised as a bug on HTML5

   fantasai: :scope, which was from selectors API 2

   tantek: I think selectors 4 should be a superset of selectors 3.
   tantek: I don't think it's reasonable to separate out pseudo-elements
           unless the splitter is writing both
   fantasai: pseudo elements need a lot of work, and I don't want to work on them
   fantasai: things like querySelector also want selectors but not pseudo-elements
   tantek: I think you should write up an explanation of the change in scope
           so we have something to point to

   glazou: If selectors 4 stabilizes, do we want to release FPWD before
           Selectors 3 is a REC, or is it a bad signal?
   dbaron: I don't think we should wait
   anne: XHR1 and XHR2 are released at the same time, hasn't caused problems
   anne: We should publish our in-development work on TR -- otherwise people
         will just always read the editor's draft.
   tantek: I think it's more confusing to have out-of-date specs.
   fantasai: I don't think it's a problem to wait a week -- wouldn't want to
             wait a couple of months.
   Tantek: I think it's more confusing to have out-of-date specs than to have
           multiple versions in different stages.
   glazou: levels and versions
   fantasai: levels vs. versions doesn't matter here
   [lots of people talking at once]

   tantek: I think it's important for selectors 4 to explain how it's different
           **and why**.
   tantek: and how to consider it in terms of it being a draft and 3 being at
   tantek: a hint that says "if you want the stable thing, go here..."
   * glazou thinks tantek suggest adding <blink>this is totally experimental
            and subject to change</blink> to the spec :-)
   Steve: a marketing subcommittee to explain to the world what we're doing
   Steve: I know a lot of people who think of css3 as a monolith.
   fantasai: The snapshot should explain this.
   * tantek shudders at the use of both "marketing" and "subcommittee" in
            the same sentence.
   <stearns> Tantek will organize the task force for selecting marketing
             subcommittee members

   glazou: anything else for selectors4?
   fantasai: Anything else we need to sync with HTML5.
   * anne updated http://wiki.csswg.org/spec/reviews/html5 a bit
   fantasai: I just went through backlog on www-style and added some of the requests.
   <anne> fantasai, http://lists.w3.org/Archives/Public/www-style/2011Jul/0415.html
   tantek: What about css3-ui having more UI selectors than selectors3, but
           selectors 4 incorporating all of the pseudo-classes but not the
   fantasai: I'm going to slurp in the pseudo-classes but not the pseudo-elements
   tantek: Need to take care to explain that.
   Steve: We've never documented to the outside world the process we use for
          making progress, how to modularize...
   anne: Link to explanation of why pseudo-elements not in this draft?
   Tantek: fantasai took an action to add that to the draft
   [discussion of explaining modularization... in snapshot ...]

   fantasai: What needs to be done before FPWD?
   glazou: Add an example to :scope?
   tantek: Do you want to include pseudo-classes that I'm looking into adding
           to css4-ui?
   fantasai: Why don't you co-edit this and add them
   tantek: accepted

   arron: What about pseudo-elements?
   arron: Is anybody going to create that?
   tantek: it may be one or more specs?
   tantek: They may be tied to particular modules.
   anne: :first-line and :first-letter could make more sense in line layout
   dbaron: :before and :after in generated content
   anne: :selection in UI
   tantek: so, fantasai, put pointers in to these new locations?
   fantasai: So pseudo-elements section here defines generic syntax and points
             to other modules

   glazou: may have to revisit second paragraph of 6.5 at some point
   glazou: it makes sense to define the class attribute for all dialects
           rather than saying it's namespace-specific knowledge
   tantek: I support Daniel's proposal.
   anne: It works in SVG and MathML-- what's the problem?
   glazou: Just say the 'class' attribute is always class.
   peter: I don't think that will fly, and is outside of our scope.
   anne: vague idea of making ID and class special in DOM core
   peter: I don't think we can do this; we'd be defining  XML.
   anne: Can't define it here, but could define it in DOM core.
   glazou: everything should have class
   dbaron: I really don't want xml:class
   fantasai: out of scope for us anyway
   fantasai: I can make the spec say it's document-language specific, which is what it should have said.

   * shepazu glazou, plinss, you want a guest?
   <glazou> shepazu: ???
   <glazou> shepazu: cookies are here, you're welcome
   <shepazu> glazou: ok, cool
   <anne> you can have a cookie
   <anne> but not be our guest

   plinss: anything else for selectors 4?
   tantek: can we make the class attribute wording more encouraging
           "(e.g., HTML, SVG, MathML)"
   fantasai: class attribute is not always 'class'
   fantasai: e.g., in docbook, the equivalent is the role attribute
   tantek: I want the spec to suggest that if you're making a new XML language,
           it should use "class" as the class attribute.
   <glazou> what about :unicorn ???
   [discussion of editorial improvements]
   [brief discussion about placeholder styling]

   <bradk> I had some pseudo-class ideas from 2007:
   <tantek> bradk - can you add those to http://wiki.csswg.org/spec/selectors4 ?
   <bradk> OK

<br duration="15m" type="cookie"/>

CSS3 Text

ScribeNick: TabAtkins
   fantasai: Just a few open issues to talk about.
   fantasai: Some we'd need jdaggett here for.
   <fantasai> http://dev.w3.org/csswg/css3-text/#white-space-collapsing
   fantasai: Right now we have text-space-collapse.  I wanted to see what people
             thought of the different values.
   fantasai: [explains the property values]
   fantasai: I think 'discard' is a behavior in MathML.
   dbaron: From TeX, I'm used to putting my footnotes exactly where I want the
           marker (considering whitespace).
   glazou: I think the consume-* are trying to fix an error on the author side.
   glazou: I think if the authors write the footnotes correctly, you don't need
   fantasai: If you represented the footnote with parentheses, you'd want the
              space there.
   fantasai: A use-case for consume-before is footnotes - you may want
             whitespace between the text and the inline note, but when you use
             CSS to pull the footnote elsewhere, you probably want the footnote
             marker to be flush against the preceding text.

   fantasai: trim-inner is similar to the behavior of <pre> (which drops the
             first linebreak), but less limited
   tantek: HTML and XHTML have a slight different in whitespace processing.
           Could this address that?
   anne: I think that's handled at the parser level, so we don't have access
         to it.
   fantasai: I added trim-inner because I currently put comments in my code
             that just wrap whitespace, so I can indent my code how I like
             without extra blank lines showing up in my <pre>.
   <dbaron> <html
   <dbaron>   ><head
   <dbaron>     ><title>...

   anne: What's the use-case for discard?
   fantasai: I think MathML discards whitespace at least some of the time
   dbaron: Our MathML impl discards a lot of whitespace.
   <dbaron> but not all of it
   dbaron: I think MathML actually has trim-inner on the token elements
           (at least ours does)
   anne: Doesn't MathML have their own rendering model?  Do they need CSS
        to solve things here?
   tantek: They're trying to move away from that and do a pure-CSS thing.
   <bradk> 'discard' would be useful for an element containing several buttons
           that are display:inline-block, and sometimes are authored with spaces
           and sometimes not.
   <bradk> Text editors that format HTML often put each button on each line
   <TabAtkins> Good case, bradk!
   <bradk> :)
   ACTION fantasai: list use cases for each white-space value
   <trackbot> Created ACTION-345

   fantasai: tab-size property.  Brad suggested a <length>.
   fantasai: Also, possibly a 'sp' unit that corresponds to the width of a space.
   tantek: What's the use-case for brad's suggestion?
   bradk: The idea is that if you're formatting code, you may have bits that
          are different font size, but you want the tabs to all be the same size.
   glazou: I suggest pinging Mozilla for the "ace" project.
   anne: I think that's only a theoretical case.
   dbaron: It would be really easy for <length> to work - right now we only
           use the integer to multiple by the width of a space, turning it
           into a length.
   fantasai: So we can add <length> and mark it as risk.
   szilles: What does Word do?
   TabAtkins: They have tab stops at explicit lengths.
   szilles: Thought so.  Presumably they have a good reason?
   anne: If the use-cases are theoretical, we shouldn't waste time on it yet.
   arronei: Different font-sizes are a use-case already.  Dragonfly doesn't
            have multiple font sizes.
   anne: Doesn't everyone use monospace?
   [several]: No, we use variable-width.
   RESOLVED: Add <length> to tab-size, mark as at-risk.

   fantasai: Only thing left is hyphenate-resource, but hakon isn't around
             right now.
   fantasai: Any objections to dropping it for now?
   RESOLVED: Drop hyphenate-resource. It can be put back if there's more impl

   fantasai: Another issue is the underline values.
   fantasai: We decided to call them cancel-underline instead of no-underline,
             but that's inconsistent with XSL.  Do we need a note?
   arronei: Why did we change it from no-underline?
   fantasai: It doesn't actually shut down underlines; it just blocks the
             parent's underline and lets you set a new one.
   [discussion about whether the naming is confusing]
   dbaron: What's the use-case for cancel-underline?
   TabAtkins: One is editting - if you remove the underline from a span of
              underlined text, every text editor makes it easy.  Right now,
              CSS's model means you have to do some very significant
   fantasai: Another is having an icon in a span of underlined text that you
             don't want underlined.
   fantasai: But those use-cases have been listed previously and decided on.
   szilles: That doesn't answer the question at hand.
   TabAtkins: suggestion - "none | [underline | cancel-underline | override-underline]
              | [overline | cancel-overline | override-overline] | [<line-through stuff too>]"
   * glazou notes than even if we have cancel-underline, Tab's case above
            will still require the creation of at least a span
   szilles: I think that it's going to be confusing for authors that you say
            "underline cancel-underline" to make the underline reset.
   dbaron: I don't know if that's enough of a use-case to justify three more
   szilles: Does SVG have underlined text?
   shepazu: SVG 1.1 only uses CSS @text-decoration, but we'd like to follow
            CSS here.
   dbaron: SVG1.1 is just the CSS2.1 text-decoration values.
   <dbaron> underline
   <dbaron> no-underline cancel-underline
   <dbaron> reset-underline new-underline replace-underline reset-underline
   <dbaron> Florian proposes don\'t-underline
   ACTION fantasai: Poll for best options on naming
   <trackbot> Created ACTION-346
   RESOLVED: text-decoration uses the "none | [underline | no-underline | reset-underline] ...",
             exact name of the new keywords TBD.

   <fantasai> http://dev.w3.org/csswg/css3-text/#text-decoration-skip
   dbaron: I think text-decoration-skip:none would be quite a bit of work
           to implement.
   fantasai: I think it's necessary, though.

   <fantasai> http://dev.w3.org/csswg/css3-text/#word-wrap
   fantasai: It was suggested that word-wrap be an alias for "overflow-wrap"
             (which is a better name).  If we do that, how is it done?
   TabAtkins: This is the same issue with object-fit and image-fit, right?
   fantasai: Theoretically yes, but the impls that did image-fit were printers
             that didn't have JS, so you couldn't introspect and it wasn't
             very widespread anyway.  It didn't matter how they accomplished
             the aliasing.
   fantasai: Also, Alex brought up that "word-wrap" has existed for a long
             time and there's a lot of documentation for it.  if we change
             that, will that hurt authors?
   szilles: Any way we can find out how many docs use word-wrap?
   ???: A lot of Word exports.
   fantasai: A lot of them are using it to work around the lack of pre-wrap.
   fantasai: If you cross out those cases, likely very few.
   plinss: every time I've seen someone look at this, they've been confused
           and think it should be controlling text-wrapping. So I think it's
           worth fixing.
   discussion about what aliasing means
   florian: We have to be very specific about whta aliasing means.  If you
            query for one of the names, does it grab the value when specified
            with the other name?
   plinss: We'd just define it as "overflow-wrap" and say "browsers may, for
           legacy reasons, accept 'word-wrap' with the same meaning".
   dbaron: For this sort of property, I'm not too interested about the effect on JS.
   RESOLUTION: Rename word-wrap to overflow-wrap, add a note that browsers
               may accept word-wrap.

   florian: We talked last time about line-break.
   florian: The definitions of the values aren't specific enough to be helpful
            and interoperable.
   florian: It was stated that we can't change it because IE has had it forever.
   florian: But if only IE does it, and nobody really knows what they do anyway,
            it seems like not a problem.
   florian: [describes a survey of websites they did]
   florian: I'd prefer having "auto", along with a list of things forbidden
            from starting a line, a list of things forbidden from ending a
            line, and things that must stay together.
   fantasai: We resolved at the last f2f to mark "loose" as at-risk.  I don't
             want to make authors choose only between "auto" and listing
   florian: I think this only works within a walled garden, where you can
            guarantee a UA and learn what it means for that.  But on the
            wider web, you wouldn't be able to depend on any of this.
   fantasai: You don't have that level of control currently in English either.
   szilles: Stated differently, in English we allow the UA to do river
            detection.  To forbid river detection seems like locking us into
            bad typography, which sounds like something we don't want to do.
   florian: The only people that want this are the japanese publishing houses,
            and they want precise control.  If we don't give precise control,
            then we're not serving anyone usefully.
   szilles: There's nothing stopping us from making this more complex and
            specific in the future.
   fantasai: I don't see this as a split between "I'm a publishing house
             that wants obsessive control" and "I'm an author and don't care".
   fantasai: Publishing software provides switches like what we have.
   alan: The modes there are just a particular publishing house's rules.
   <bradk> Is it testable the way it is now?
   <TabAtkins> Brad: no
   <bradk> Well then... it really does need to be more exact, doesn't it?
   alan: I don't think it's really about line-break control; the important
        thing is just ensuring that particular characters don't ever end a line.
   florian: If a publishing house cares enough about linebreaking (all their
            books looks a particular way), they might very well block a browser
            that doesn't act the way they want.
   florian: They'll either give up control, or just block everyone who doesn't
            give them the right level of control.
   szilles: The question here is, are we eliminating moving to that capability
            in the future?  If we're not blocking that, it's not too bad of a
            problem; we can fix it later.
   alan: If we later make it more precise, will the existing values become
   szilles: I think there's a significant group of authors who care enough
            about this to set the property, but not enough to dive into
   szilles: This seems appropriate for "newsletter"-level support, though it's
            not yet good enough for precise publishing-house-level control.
   fantasai: We can do something like @counter-style in the future for defining
             more complex things.
   szilles: I'd like a note to say something about how additional controls may
            be introduced in the future to handle more precise controls.
   florian: Does anyone know how this would work in other languages that don't
            break on spaces but aren't CJK?
   szilles: Thai is the classic example, and there you need a dictionary to
            do breaking.
   kojiishi: In Thai, there are some places you can define as being generally
             very bad to linebreak on, without having to resort to a dictionary.
             Not perfect, but better than nothing.
   fantasai: The handling of codepoints outside was minuted in Kyoto.
   florian: While I don't like the current stuff, I'm okay as long as there's
            the possibility of additional control in the future.
   RESOLVED: No change to current line-break property, add note about future
             extensions for more precise control.

CSSOM Serialization
ScribeNick: fantasai

   TabAtkins: We have some rules for how we should serialize things in the
              CSSOM module
   TabAtkins: I have some rules in CSS3 Images
   TabAtkins: These are different in their strategy
   <shepazu> (the term for languages that don't use spaces as word separators
             is "scriptio continua", and was used in Latin and Greek in the
             Dark Ages)
   TabAtkins: CSSOM omits everything it can
   TabAtkins: Mine is very verbose
   TabAtkins: Would like to figure out how we want to serialize things
   TabAtkins: And maybe put this all in one place
   TabAtkins: Almost all the serialization things I have in css3-images
              depend on serializing more basic types, which aren't defined
   Anne: CSSOM has a section on common serializing idioms
   Anne: Serializing character identifier, string, etc.
   Anne: Then there are things less well-defined
   Anne: What I followed there was an old proposal by hixie on how to
         canonicalize CSS property values, and in that proposal he suggested
         omitting things
   Anne: and I sortof think that makes sense
   dbaron: Two general principles I think about for serialization ...
   sylvaing: One thing that's controversial was following the property
             definitions in terms of property order
   sylvaing: I remember dbaron was uncomfortable with that
   Anne: I think the properties should define that for themselves
   fantasai: You were supposed to give us a template for that

   dbaron: The two principles I think of
   dbaron: One is, if something that can be serialized in a form that is
           more backwards-compatible, always prefer the older form
   dbaron: This is why I serialize transparent as 'transparent' instead
           of 'rgba(0,0,0,0)'
   dbaron: The other one is that DOM Level 2 Style does explicitly style
           that there should be a preference for shortest form
   dbaron: Although that's specifically for serializing shorthands
   dbaron: I think if we want to pick one way or the other, we might want
           to pick that.
   dbaron: Although there's some ways where it's dangerous, e.g.
   TabAtkins: There's 2-3 times you have to be careful about ordering there,

   Anne: Do all these drafts, if they want to define serialization, will
         they all depend on CSSOM?
   Anne: How do we move forward?
   Anne: I think we only want to define serializing URL once, frex
   sylvaing: ... sometimes longer form is easier
   dbaron: I think biggest issue with serialization is question of what
           information is retained and what information is lost
   dbaron: We have 2 different serialization.
   dbaron: specified values vs. computed values
   dbaron: the information lost in those two is substantially different
   dbaron: For specified values, I try to mostly minimize information loss
   dbaron: Some things are lost, e.g. whether double or single quotes were used
   glazou: Color format?
   dbaron: We may lose rgb vs hex
   dbaron: but we do give back keywords
   glazou brings up Web-based editors
   dbaron: Another dangerous thing about loss of information issues..
   dbaron: Some of these are deeply hardcoded into implementations
   dbaron: Might be difficult to align implementations on this.
   glazou: Some of the losses are due to performance hits.
   fantasai: There was a proposal to have an API that returns the value as
             the string parsed in
   glazou: But that's a lot of memory. For an editor, it's perfect, but
           for a browser it's a lot of performance problems.

   dbaron: What did you want out of this discussion?
   TabAtkins: In magical perfect world, somebody would say "here's how we
              should serialize things", and then I can go work on that.
   glazou: Timing function for transitions? What should I do? Output bezier
           or output keywords?
   glazou: Perhaps first if you can output as a keyword, output the keyword
   TabAtkins: If I want to write good serialization rules, how should I do it?
   dbaron: Essentially you're specifying what information is lost and what isn't
   dbaron: And when it is lost, which way do you choose to fill it back in.
   dbaron: Going back.. Principle 0 of serialization -- many browsers get
           this wrong--
   dbaron: The thing your serializer outputs should be valid input.
   sylvaing: roundtripping
   dbaron: Before I started writing tests for this in Gecko, there were many
           places where this was not true and nobody noticed.
   <dbaron> the thing that's easily testable is that the function (parse +
            serialize) is idempotent
   glazou talks about -webkit-gradient, Tab asserts this is out-of-scope
   Tantek clarifies principle 0: The point wasn't that you roundtrip from
          the original. The point was that what you output, that should
          roundtrip exactly.
   dbaron: No, if you parse and serialize and reparse, you should get the same
           results that you got the first time.
   dbaron: An easy way to test that is to serialize again and check that
           against the first serialization.

   Tantek: We're going to keep adding features to CSS.
   Tantek: The serialization today will always be a subset of the serialization
           tomorrow. And that's okay.

   glazou: One serialization to discuss -- the 'border' shorthand.
   glazou: In some cases we can serialize (lists shorthand combos)
   glazou: How should we do that?
   glazou: Do we try to minimize number of properties we declare?
   dbaron: There's question of how to serialize a particular property,
   dbaron: And how to serialize a declaration block.
   dbaron: That's the second quesiton
   glazou: If the strategy is to minimize number of declarations, you can
           wind up with same number in different forms.
   dbaron: I think we try shorthands in alphabetical order, and pick the
           first one that works.
   TabAtkins: Sounds like I should make serialization rules informative
              in css3-images
   [various side-conversations on serialization]
   ACTION glazou: Write collection of serialization heuristics
   <trackbot> Created ACTION-347

CSS3 Conditional Rules FPWD

   dbaron: There's one issue left I want to solve before FPWD, but never get
           to, so maybe publish first.
   dbaron: The issue isn't sometihng we'll find a lot of expertise on in
           this room.
   dbaron briefly summarizes what's in css3-conditional
   dbaron: The remaining issue is what normalization happens to URLs before
           comparison occurs
   dbaron: I know some people who work on the URL spec, and therefore are
           likely to be able to offer concrete advice.
   Anne: What do you mean by normalization?
   dbaron: Defining what is the URL of the page, i.e. "this url", and how
           you do the comparison.
   dbaron: I need to dig through the URL spec and figure this out
   fantasai: I think we should mark this as an issue and publish.
   dbaron: Need to know which RFC to point to, and which variation on
           matching rules
   Anne gives some examples of what the variation sare
   plinss: You could fetch the URL and see if you get redirected to something
           else. :)
   RESOLVED: Mark this as an issue, publish FPWD of css3-conditional.

View Mode Media Feature, Media Queries, MQ test suite

   Arron: John's topic
   sylvaing: View Mode is in PR, and it depends on Media Queries
   Anne: The only reason MQ hasn't advanced is because we don't have passes for
         the test suite
   dbaron: Presumably they had a test suite that didn't check the parsing rules.
   dbaron: Our issue blocking MQ is getting implementations to pass the tests
           we have
   Arron: There are also bugs in the test suite. I have a list.
   ACTION Arron: Send MQ test suite bugs to mailing list
   <trackbot> Created ACTION-348
   dbaron: We have one passing implementation, because I implemented and wrote
           the tests and passed the tests.
   Anne: We added some tests from Acid3
   Anne: I cross-checked with tests I already wrote.
   Anne: I guess we have to wait for bug reports on MQ test suite
   Arron: One case is handling of number and dpi values
   Arron: dpi is supposed to be an integer, however is defined as <number>dpi,
          which means you can have a decimal point in dpi
   Arron: Other cases here I'll list
   Arron: is 92.6dpi still valid?
   dbaron: yes
   dbaron: You're right that there's a bug in FF on this.
   dbaron: I think the spec may have changed on this...
   <anne> dbaron, I think in 2007 it was not defined
   <anne> dbaron, whether it should be <number> or not


   glazou: Back to question I asked last F2F.
   glazou: I think we should spend more time on testing Transitions and Animations.
   glazou: Web authors are relying on this a lot
   sylvaing: Every time we define a new property, we need to figure out
             how it animates
   glazou: We'd have to test every property?
   dbaron: Testing every transitionable property is easy, set a 4s transition
           with -1s delay
   dbaron: That doesn't test the timing function, but it tests the interpolation
   dbaron: Testing the timing function is harder
   Dean: I think the way to make progress is to make progress on the query
         animation api
   Dean explains the api.
   Dean: That'll make it easier to run tests.
   dbaron: The way I wrote our tests was to add an api that artificially
           advances the clock.
   dbaron: Just one api
   Dean: ..
   dbaron: Exposing stuff isn't sufficient, because you need to be able to
           cause a particular change at a particular time, and test the
           effects of that.
   dbaron: You need to test things like, what happens if I cause a property
           change halfway through this transition.
   dbaron: With an API that just advances the clock, you can test things
           like that.
   dbaron: Maybe I don't understand the API you're propsing
   Dean: well, it doesn't exist
   Dean describes how horrible WebKit's api is
   dbaron: Our timing code is relatively centralized, so we have some code
           that says "ignore the clock, just listen to the updates from me"
           and then "advance 1s, advance 2 s, advance 20s"
   Dean describes going back in time.
   and running animations backwards
   Arno: When you're building an animation with a tool like our HTML5
         animation authoring tool, you want to navigate a timeline
   Arno: E.g. pretend the time is X, and show that
   Dean: I've found it's easier to write tests that way than any purely
         content-based ones
   Dean: If we define an API and all implement it, then we can all run tests.
   dbaron: An API like that doesn't work going backwards.
   dbaron: Once an animation is done, it's done, and no longer animating.
           You can't go backwards
   dbaron: For the record, I wrote our transitions tests without this API
   dbaron: It's a combination test that runs over an 8s period. It uses
           setTimeout to get its time samples
   <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_2_-_spot-testing_with_pre-defined_document-times
        is the proposed method of testing declarative animations in SVG
   dbaron: ...
   Dean: ...
   dbaron: When you're running the tests 100s of times a day, and you need
           to get the failure rate down to <1 once every 6 months ...
   Vincent:... You can set timeline and pause it
   glazou: We will need more things like that, e.g. when you resize Regions.
   Arno: But that's not time-based.
   glazou: We also have another time-based spec, CSS3 Speech
   fantasai: You can do a lot of reftests with that one.
   fantasai gives an example
   Vincent: Did we agree on anything for testing animation?
   glazou: I think we need some kind of debug API
   dbaron: I think we need proposals.
   Vincent: Ok, let's discuss this at hte fxtf
   glazou: We have a lot of specs on the radar, and a lot will reach CR in
           the next 6 months
   glazou: We need a lot of help on specs
   sylvaing: It was suggested that each spec have a testing owner.
   dbaron: The more effective step we discussed is that if you want to ship
           it unprefixed you have to contribute a test suite.
   Steve: Separate question of when is the right time to start developing a
          test suite.
   Steve: In some sense CR is too late, and is another sense it's when it's
          finally stable enough.
   glazou: You should write a test as you write the spec.
   dbaron: Tests are hard to maintain.
   Florian: It's more overwhelming if you don't start early
   dbaron: It's harder to keep the tests in sync with spec change is to test
           in in an implementation that supports the feature.
   glazou: shrug
   dbaron: A problem with that is that the tester might miss something in the
           spec, and write the test.
   dbaron: And then an implementer ignores the spec in order to pass the test
   dbaron gives an example of this happening
   dbaron: We should be careful about advertising the quality of the test suite
   shepazu: SVG's tests advertise their stability level

   Arron: One thing we really need is better tracking.
   plinss: I'm actively developing a tracker for that. It will be online,
           hopefully, in a few weeks.
   plinss: This is a new system, it's tightly coupled to the Mercurial repo,
           and tied itno test suite build system.
   plinss: I'm actively working on that. It's what I'm doing now.

Meeting closed.

Received on Saturday, 30 July 2011 00:37:07 UTC