- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 29 Jul 2011 17:36:24 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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.
Testing
-------
- 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:
http://wiki.csswg.org/planning/2012
<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
<bradk>
http://maps.google.com/maps?q=microsoft&hl=en&ll=21.316243,-157.859459&spn=0.284973,0.260239&sll=20.128155,-157.016602&sspn=9.182145,8.327637&gl=us&z=12&iwloc=A
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
February
<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:
http://lists.w3.org/Archives/Public/www-style/2007Nov/0108.html
Tantek: Did you document the scope of the spec as not including
pseudo-elements?
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
PR/REC
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
pseudo-elements
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:
http://lists.w3.org/Archives/Public/www-style/2007Nov/0108.html
<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
that.
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
interest.
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
tag-juggling.
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
values.
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
codepoints.
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
obsolete?
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
codepoints.
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.
animations/transitions
TabAtkins: There's 2-3 times you have to be careful about ordering there,
yeah
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
Testing
-------
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
code
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