Re: Intent to prototype and ship: CSS `quotes: auto`
On 7/8/19 3:53 AM, Jonathan Kew wrote: Summary: Adding a new `auto` value as the initial value of CSS `quotes` property, with the behavior that language-sensitive quotation marks (derived from CLDR) are used for quote-open/close generated content. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1421938 Standard: https://drafts.csswg.org/css-content-3/#quotes (not yet updated to reflect recent WG resolution) Updated spec, and requested publication so hopefully should hit http://www.w3.org/TR/css-content-3/ later this week. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: built-in CSS counter 'list-item'
On 3/27/19 5:19 AM, L. David Baron wrote: On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote: FYI, the CSS Lists spec isn't very well maintained, sadly, so it's not up-to-date with recent resolutions. So, some of the finer details in there might be wrong, but I think most of it regarding counters is correct. If you've been implementing based off of resolutions that aren't in the spec, it's probably worth submitting PRs to the spec so that other future implementors are aware of those resolutions and you don't have to later go and undo the effects of those resolutions for compatibility. Since I just ran across this thread, current status of the spec is a lot better: https://lists.w3.org/Archives/Public/www-style/2019Apr/0024.html ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship the CSS Scroll Snap Module Level 1 and unship old scroll snap properties
All of this sounds great to me, and I'm pretty excited that Mozilla will
be updating to the latest spec. Most of the changes were in response to
roc's feedback on the spec, and make it a much more robust system for the
variable environment of the Web.
There's a couple things I want to make sure you watch out for and get
right before shipping:
1. Handling overlarge snap areas per
https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
This is important to make content accessible on smaller-than-expected
screens.
2. Handling scroll-padding correctly even when snapping is turned off,
since it should affect all paging operations and scroll-into-view
operations. https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding
3. Likewise, supporting scroll-margin's effects even when snapping is off:
it still be adjusting the element's scroll-into-view area
https://www.w3.org/TR/css-scroll-snap-1/#scroll-margin
Also, feel free to complain at me if anything in the spec is unclear. :)
https://github.com/w3c/csswg-drafts/issues
IRC: fantasai
Bugzilla: fantasai.b...@inkedblade.net
~fantasai
On 3/8/19 4:51 PM, Hiroyuki Ikezoe wrote:
Summary:
The scroll snap specification has been significantly changed since we
implemented. scroll-snap-coordinate, scroll-snap-destination and
scroll-snap-points-{x,y} were dropped, instead, scroll-snap-align,
scroll-snap-margin and scroll-snap-padding were added in the spec. Also,
scroll-snap-type was changed to a longhand property and its syntax was
changed in the spec.
Due to the scroll-snap-type change, this migration will happen
irreversibly
in terms of the scroll-snap-type property. Once the change happens in bug
1312163 [1], you can no longer use the old longhands,
scroll-snap-type-{x,y},
and no longer use the old shorthand syntax like `scroll-snap-type:
mandatory`.
That means that, for example, sites specifying only scroll-snap-type-x will
be broken. To mitigate it, I am going to land a bunch of relevant stuff
at the
same time so that we can switch to the new scroll snap at once.
Bug:
A meta bug is
https://bugzilla.mozilla.org/show_bug.cgi?id=1231777
Link to standard:
https://drafts.csswg.org/css-scroll-snap-1/
Platform coverage: all
Estimated or target release: Firefox 68
Preference behind which this will be implemented:
layout.css.scroll-snap-v1.enabled
Is this feature enabled by default in sandboxed iframes?
Yes
DevTools bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1133666
Do other browser engines implement this?
Chrome and Safari already shipped
web-platform-tests:
http://w3c-test.org/css/css-scroll-snap/
Additional notes:
scroll-snap-stop which was introduced in the new spec is not going to be
implemented now since it's marked at-risk in the spec
Thanks,
hiro
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1312163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: forced case-sensitive attribute selector matching
On 12/11/18 6:34 AM, Boris Zbarsky wrote: > > Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny change and there's not much controversy about which letter to use for the flag, I would think. As the editor of the spec, I second this assessment. There are parts of Selectors 4 that are a little shaky, but this is so closely analogous to an existing feature that it doesn't seem like one of them. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Overflow media queries
On 12/23/18 2:59 AM, Emilio Cobos Álvarez wrote: Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using a media expression instead of the print media type allows for more flexibility, see the bug description. Implementation wise, we already expose the same kind of information via @media print right now, given we don't have any kind of built-in EBook mode or something like that. A volunteer sent patches for this, and I see no reason not to take them, unless somebody objects here. Thanks a lot quasicomputational@! :) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1422235 Link to standard: https://drafts.csswg.org/mediaqueries-4/#mf-overflow-inline https://drafts.csswg.org/mediaqueries-4/#mf-overflow-block Platform coverage: all Estimated or target release: 66 Preference behind which this will be implemented: None Is this feature enabled by default in sandboxed iframes: Yes DevTools bug: N/A, existing devtools features should cover this. Do other browser engines implement this? No, we'd be the first ones implementing this part of the spec, but I think it's uncontroversial. The spec author was the one that filed the bug requesting implementation, so spec-wise the feature should be stable as well. General CSSWG policy is that any spec in CR has the consensus of the CSSWG to be implemented and shipped. “Once a specification reaches the Candidate Recommendation stage, implementers should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec, and should avoid exposing a prefixed variant of that feature.” -- https://www.w3.org/TR/CSS/#testing Media Queries Level 4 is in CR, so anything there is good to go. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands
On 1/14/19 10:23 AM, Boris Zbarsky wrote:
On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline
Two quick questions on the spec:
1) 'padding-block-start' is defined as:
Value: <‘padding-top’>
while 'padding-block' is defined as:
Value: <‘padding-left’>{1,2}
It probably doesn't matter too much because padding-top and padding-left have the same value space,
but it's a bit weird and makes one go sleuthing to ensure that they do. Do you know whether this is
purposeful or just a typo?
I have no idea why I did that. Fixed.
2) We are just implementing the padding shorthands for now, not the margin ones?
Do other browser engines implement this? No,
https://wpt.fyi/results/css/css-logical/logical-box-padding.html
Do they plan to? That is, is the spec reflecting some sort of general
consensus?
Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
https://www.w3.org/TR/css-logical-1/#intro
~fantasai
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: How do I file a bug?
On 10/04/2018 04:26 PM, Steve Fink wrote: On 10/04/2018 03:45 PM, fantasai wrote: Start here, at Mozilla's home page: https://www.mozilla.org/ Give me steps to reproduce to find instructions for filing a bug against Firefox. Ditto for up-to-date instructions for building the source and submitting a patch. (Don't send me links to the instructions; I'm cheating by asking here already. Walk me through the process of discovering how I can contribute to Mozilla and make the world a better place. I wouldn't be here if I hadn't already walked that path 19 years ago, but I can't find it anymore so I need some help.) I tried it out, and did better than I expected on my first run-through: [...] I'm impressed! Want to take a stab at finding patch-submission instructions? :D > I agree that a nice path from www.mozilla.org would be beneficial, > especially for promoting the volunteer aspect of the project. We've got a lot of highly-produced (read: expensive) material promoting the volunteer aspect of Mozilla: https://www.mozilla.org/en-US/contribute/ But afaict none of it actually leads to a viable path towards actually becoming a technical contributor... From my discussions with staff at Mozilla, the people actually working with volunteers (like QA and l10n) find this very frustrating, but the people whose job it is to connect volunteers to opportunities to contribute don't think it's useful, important, or in some cases even a good idea to fix this problem. I don't know how to break through that resistance, and I find it very demoralizing that there even is any. :( I'm also disconnected enough from Mozilla the last few years that I've no idea where up-to-date documentation on this stuff would live. If I ever manage to dig myself out of the backlog of spec work enough to write a patch, I'd like to know where to look! Fwiw, here's how I arrived at becoming a technical contributor: https://web.archive.org/web/2125153750/http://www.mozilla.org:80/ https://web.archive.org/web/2301043132/http://www.mozilla.org:80/get-involved.html https://web.archive.org/web/2302035824/http://www.mozilla.org:80/quality/bug-writing-guidelines.html https://web.archive.org/web/2304015940/http://www.mozilla.org:80/newlayout/bugathon.html “One of the things that people seem to like best about the existing content on mozilla.org is that it is written by people, for people, without bluster or self-promotion.” -- jwz, Mozilla Documentation Style Guide, 1999 ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How do I file a bug?
Start here, at Mozilla's home page: https://www.mozilla.org/ Give me steps to reproduce to find instructions for filing a bug against Firefox. Ditto for up-to-date instructions for building the source and submitting a patch. (Don't send me links to the instructions; I'm cheating by asking here already. Walk me through the process of discovering how I can contribute to Mozilla and make the world a better place. I wouldn't be here if I hadn't already walked that path 19 years ago, but I can't find it anymore so I need some help.) ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: support CSS paint-order for HTML text
On 12/24/2017 04:54 PM, James Graham wrote: On 24/12/2017 13:13, Emilio Cobos Álvarez wrote: On 12/24/2017 02:01 PM, Jonathan Kew wrote: Tests - Is this feature fully tested by web-platform-tests? No, as it is not yet spec'd (see above). I propose to land a basic mozilla reftest along with the patches in bug 1426146 (behind a pref); if/when the CSS WG agrees to accept this issue in the spec, we can migrate the reftest to WPT Just FYI, other people land tests into WPT with .tentative.html in the name, like: https://github.com/w3c/web-platform-tests/pull/8602 Not sure what's preferred, I believe that if the chances of this getting spec'd are high it may be better, but... James, do you know whether there's any official guideline for these kind of situations? The .tentative.html thing is an accepted convention for stuff that tests the presumed behaviour of a future spec, although it's possible that there aren't any CSS tests using the pattern yet. I would certainly encourage using it here rather than having to remember to upstream a test at some later date. As the editor of the spec in question, I can say that the only reason the issue was open was because we were looking for some combination of implementer interest and/or confirmation that this is a sane thing to do. jfkthame's intent to implement is even more formal of a confirmation than we were looking for. :) I should be able to run it officially past the CSSWG in a few hours, also, and will prioritize the edit to remove the issue for like tomorrow or something if that makes things easier. :) ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS media queries, interaction media features
On 10/03/2017 01:12 PM, Thomas Wisniewski wrote:
Summary: Implement the CSS features [any-]pointer:{none|coarse|fine} and
[any-]hover:{none|hover}
> ...
How stable is the spec: the last point of contention that I'm aware of was
resolved by other vendors a year ago when the "on-demand" feature was
dropped from the draft spec.
The spec is in CR, which in the CSSWG represents a consensus that the draft
is design-complete and vendors are encouraged to ship in public releases.
https://www.w3.org/TR/mediaqueries-4/
https://www.w3.org/TR/CSS/#unstable
~fantasai
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: SVG Working Group
On 06/23/2017 02:44 AM, L. David Baron wrote: The W3C is proposing a new charter for: Scalable Vector Graphics (SVG) Working Group https://www.w3.org/2017/04/svg-acreview-2017.html https://lists.w3.org/Archives/Public/public-new-work/2017Jun/0006.html Mozilla has the opportunity to send comments or objections through Monday, July 17. (Note that there was a previous review in December; this proposal replaces the proposal in that review.) Note that this charter reduces the scope of the SVG working group (transferring all joint work between SVG and CSS to CSS only) with the plan to use the time in the charter to complete SVG2, which now includes the SVG Integration work. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. I think you should ask Amelia Bellamy-Royds for her thoughts, as I think her participation would be critical to the success of the SVGWG and she likely has detailed insight into the appropriateness of the charter and its various clauses. I'll also note that as an Invited Expert she has not been asked to comment on the proposed charter... while the CSSWG typically invites all its members to review the charter prior to proposing it to the AC, afaict this has not happened for the SVG charter [1]. [1] https://www.w3.org/Search/Mail/Public/search?type-index=www-svg&index-type=t&keywords=charter ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS text-justify property
On 02/08/2017 11:28 AM, Boris Zbarsky wrote: On 2/8/17 5:08 AM, Jeremy Chen wrote: Link to standard: https://drafts.csswg.org/css-text-3/#text-justify-property How stable is this spec? Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set of functionality is stable, even if the actual names of the values are not, implementing makes sense. Not especially unstable, but IIRC there's a number of outstanding edits, which is the main thing holding up the updates to /TR. The spec was previously in Last Call, so expected changes are mainly bugfixes. Open issues relevant to text-justify: https://github.com/w3c/csswg-drafts/issues/853 https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-116 https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117 (I vaguely recall this being resolved, but it's clearly not updated) ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: support "basic shapes" for the CSS 'clip-path' property
On 02/07/2017 04:00 AM, Boris Zbarsky wrote: On 2/7/17 3:03 AM, Ku(顧思捷)CJ wrote: https://drafts.fxtf.org/css-masking-1/#the-clip-path https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes How stable are these specs? They don't seem to be anywhere near CR, and while I realize that's not a requirement, it would be good to have them be at a _slightly_ higher maturity level than "whatever the editors wrote today" [1] https://www.w3.org/TR/css-shapes-1/ is in CR as of March 2014 https://www.w3.org/TR/css-masking-1/ is in CR as of August 2014 * though David Baron raised a number of significant issues about mask types ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS property `line-height-step`
On 03/31/2017 07:55 AM, L. David Baron wrote: On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote: **Summary** I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier. **Link to standard** CSS Rhythmic Sizing <https://drafts.csswg.org/css-rhythm/> So in the discussions in the working group, I've been somewhat skeptical that this feature does a good job of addressing the design use cases that it's intended to address. As the co-editor of the spec, I agree with David Baron's concerns. Also, based on my discussions with Dave Cramer (CSSWG member who works in the publishing industry), my understanding is that the the most common problems are situations that need to be solved with block height stepping, not line height stepping. An author can fairly easily ensure that, within a paragraph, the line height follows a strict vertical rhythm: as long as the text is not interrupted by atomic inline content or text that has a larger font size / different vertical alignment (and this covers the majority of text), it will maintain rhythm. But when the paragraph text is interrupted by different content such as illustrations and headings, then the rhythm can be thrown off. These are block-level intrusions into the rhythm, and won't be solved (without hacks like turning them into inline-blocks) by line height stepping. But they are solved by block height stepping (which is also outlined in that draft). I think we should endeavor to avoid “solutions” that require hacks, so my advice would be to implement block height stepping first, since it will more directly solve most of the use cases. I'm less convinced that line height stepping is necessary; and also there are many issues with inline layout that need to be addressed before it can be an effective solution to the problems it addresses. * Note that even for headings, which are text, it is the margin-box of the heading as a whole which needs to fit into the rhythm, not necessarily each line of it; headings usually have large margins, but the text is set closely between lines. Similar concerns apply to blockquotes with smaller text, figures with captions, and other block-level interruptions to prose. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Spec workshop: Grid Layout
I've started doing a series of workshops inviting web authors to get together and do an in-depth study of some of the CSS layout specs together, the goal being to find problems and improve readability. If this seems interesting to you, there's more information here: http://fantasai.inkedblade.net/style/events/flex-workshop http://fantasai.inkedblade.net/style/events/grid-workshop I'm planning to organize one for Grid Layout in the SF Bay Area this month and NYC next month; but I also think people here who want to could probably do a good job running one themselves wherever is convenient. :) The formula is summarized by Simon Sapin here: https://twitter.com/SimonSapin/status/658219116797427712 and more detailed instructions are in the flex workshop page. If you do, please send any feedback back to the spec editors, e.g. to www-st...@w3.org for CSS. Happy coding~ ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Selectors to Standardize
So after a nearly 2 year hiatus, I'm back to editing the Selectors 4 spec... I'm looking over the set of -moz- selectors http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPseudoClassList.h and wondering which ones we need to put on the standards track. (A) So far we already have on the standards track :-moz-only-whitespace as :blank http://www.w3.org/TR/selectors4/#the-blank-pseudo **Please, if you all have better name suggestions, we welcome them.** [ :blank imho sounds like a blank form element, which we might want a selector for in the future. :/ ] :-moz-any() as :matches() http://www.w3.org/TR/selectors4/#matches :-moz-any-link as :any-link http://www.w3.org/TR/selectors4/#the-any-link-pseudo :-moz-dir() as :dir() http://www.w3.org/TR/selectors4/#the-dir-pseudo Unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=859301 :-moz-read-only as :read-only ?? :-moz-read-write as :read-write ?? http://www.w3.org/TR/selectors4/#rw-pseudos These were pushed to CR in http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw along with the other form-state pseudos, so I'm not sure why they're still prefixed. Are there issues with these selectors that we need to sort out? :-moz-ui-invalid as :user-error http://www.w3.org/TR/selectors4/#user-pseudos :-moz-placeholder sortof as :placeholder-shown http://www.w3.org/TR/selectors4/#placeholder due to requests for ::placeholder as a pseudo-elements :-moz-drag-over as :drop or :drop() https://drafts.csswg.org/selectors-4/#drag-pseudos (B) Things I'm guessing we want to standardize: :-moz-ui-valid https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-ui-valid (C) Things I'm guessing we don't want to standardize: :-moz-empty-except-children-with-localname :-moz-bound-element :-moz-is-html :-moz-native-anonymous :-moz-system-metric :-moz-locale-dir :-moz-table-border-nonzero :-moz-devtools-highlighted :-moz-handler-clicktoplay :-moz-handler-playpreview :-moz-handler-vulnerable-updatable :-moz-handler-vulnerable-no-update :-moz-handler-disabled :-moz-handler-blocked :-moz-handler-crashed :-moz-math-increment-script-level :-moz-lw-theme :-moz-lwtheme-brighttext :-moz-lwtheme-darktext (D) Things I can't tell whether they're things we should standardize: :-moz-first-node :-moz-last-node :-moz-window-inactive :-moz-full-screen :-moz-full-screen-ancestor :-moz-focusring :-moz-broken :-moz-user-disabled :-moz-suppressed :-moz-loading :-moz-type-unsupported :-moz-type-unsupported-platform (E) Things I'm totally confused about: :-moz-meter-optimum :-moz-meter-sub-optimum :-moz-meter-sub-sub-optimum Seem to be explained by http://blog.teamtreehouse.com/use-meter-progress-elements except a lot of stuff mentioned there is not in the codebase?? My questions are 1. Is there anything above that's not on the correct list? 2. Can you help me sort list (D)? 3. Anyone have a better name for :blank? 4. Let me know what's up with :read-write and :read-only? 5. Please review the :drop spec for correctness/sanity~? https://drafts.csswg.org/selectors-4/#drag-pseudos 6. Ditto :user-error https://drafts.csswg.org/selectors-4/#user-pseudos 7. Any other comments? Thanks~ ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Better Test Case Coding for Reviewers
[CCing m.d.platform, since it might be helpful for layout tests there, too.]
I've been reviewing some tests lately, and there are three things that
would help a lot in a correct and efficient review.
#1: Good indentation.
The contents of each block should be indented. It's much harder to
read the style sheet if this is not true. I've seen quite a few tests
that have this problem. :(
#2: Separating framework from variation.
Most tests have code that sets up a framework to reveal the results
of a test, and then code that sets up the specific situation being
tested. The framework does not vary from test to test within a set,
but the test declarations do.
For example, in a test for background positioning, there will be
rules to set up a box, e.g. width, height, border, padding, margins,
color, background-repeat, etc. These are the framework declarations.
They do not vary by test within the set. Then there will be rules
that set up the test, e.g. background-position, background-origin,
background-size. These vary by test.
If there are gratuitous differences in formatting, ordering,
indentation, of the framework declarations, or if the test mixes
the framework declarations with the test declarations, then I have
to review the entire framework for every test in the series, because
I'm not sure what's changed.
However, if the framework declarations are kept constant, and the
test declarations -- the part that varies per test in the series --
are pulled out and isolated into their own part of the style sheet,
then I can quickly review an entire series, and I am less likely to
make mistakes in the review.
For example, for test file 1
/* Framework */
.container {
border: solid 3px 5px 7px 2px;
padding: 11px 17px 19px 13px;
margin: 1em;
background-image: url(support/swatch-green.png);
background-repeat: no-repeat;
}
/* Test */
.container {
background-position: center;
}
and test file 2
/* Framework */
.container {
border: solid 3px 5px 7px 2px;
padding: 11px 17px 19px 13px;
margin: 1em;
background-image: url(support/swatch-green.png);
background-repeat: no-repeat;
}
/* Test */
.container {
background-position: left;
}
I can quickly see, at a glance, that the framework has not changed.
And that the only difference in the two tests is that 'center' was
replaced with 'right' in the background-position rule.
#3: Declaration of intent
If the test writer tells me what they're trying to test, specifically,
in this test, rather than having me guess from the source code, I'm
much more likely to detect when they're failing at their job, either
by flat out not triggering the right situation at all, or by not
checking some modes of failure. (I see both of these happen often;
it is not a theoretical problem.)
The CSSWG tests have a field for this purpose,
but, really, a genuinely useful comment in any format would help.
We comment our functions to say what they're supposed to do, but
for some reason we don't think it's necessary to do this for tests.
Non-trivial tests should have a comment stating their raison d'être.
~fantasai
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Busy indicator API
On 07/05/2015 11:11 AM, Anne van Kesteren wrote: A while back there have been some requests from developers (seconded by those working on GitHub) to have an API to indicate whether a site is busy with one thing or another (e.g. networking). They'd like to use this to avoid having to create their own UI. In Firefox this could manifest itself by the spinner that replaces the favicon when loading a tab. Is there a reason we shouldn't expose a hook for this? Not having any context, I don't actually understand what you're requesting. Can you give an example, maybe? ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
License Your Mozilla Tests Under CC0!
Mozilla just announced that all tests and related resources will be available as public domain going forward and retro-actively for all tests for which they own the copyright. However, there's a lot of contributors here who own their own copyrights on tests, and would need to license separately! Also, a lot of Mozilla employees and contractors contribute under their non-mozilla.com accounts (which makes it hard to tell they're covered) or have made test contributions before/after working for Mozilla (which are not covered). Therefore Gerv created a registry in Bugzilla: to relicense your contributions, or to clarify that your contributions are in fact covered, copy-paste his legal text, and put it in a comment in bug 1073556. https://bugzilla.mozilla.org/show_bug.cgi?id=1073556 Easy peasy. Just don't forget to uncheck the CC box. :) Follow-ups to m.legal. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extending the text-overflow/overflow property to support fading out
On 05/21/2013 05:31 PM, Jonathan Watt wrote: The design for the Australis theme refresh calls for tab text that needs to be truncated to be faded out instead of using an ellipsis. This fade should be a fixed width (say 2em) regardless of the width of the tab, and apparently needs to work over non-solid color backgrounds (so a right-aligned over the top with a fading out gradient won't work). Unfortunately we don't seem to have a good way to do that right now. Using an SVG mask containing a rect with a gradient fill you can kind of get close, but the width of the fade will vary with the width of the object to which the mask is being applied. (Extending SVG length attributes to support CSS calc() would help, but that's far from trivial.) One way to cater for this use case is perhaps to extend the 'text-overflow' property to take a value |fade | or |fade()| or something. Another more general solution might be to extend the 'overflow' property to take a value |fade-rect(, , , )| or something like that. Thoughts? First thought: I don't think this belongs on 'overflow'. That says how to handle overflow, not how to style the visible content. 'text-overflow: fade ' seems to make sense to me. But I can also see cases where you'd want to fade other kinds of overflow, too, though. I've also seen cases where you want to overlay a gray-transparent gradient, though, so it's not necessarily a fade that's wanted. Another consideration: do we want here a linear gradient or a Gaussian or some other curve? Also, this should probably go to www-style. ;) Wrt working around the SVG mask issues -- see the CSS Masking spec. It should handle what you want. The main issue is how to trigger it only when there's overflow. https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C test-writing event in Paris / Beijing
Test the Web Forward registration is now open for Paris (26-27 Oct 2012) http://testtwfparis.eventbrite.com/ http://testthewebforward.org/paris-2012.html There's also an event in Beijing (in Chinese only) 20-21 Oct 2012: http://testthewebforward.org/beijing-2012.html This is a community event where a bunch of experts from various W3C groups will be teaching newbs how to write conformance tests for W3C technologies like CSS, SVG, and others. The goal is to learn, teach, and grow the Web standards-testing community. If you want to participate or you want to help out, join the event; it's free. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Internationalization Working Group
On 09/06/2012 05:26 PM, L. David Baron wrote: W3C is proposing a revised charter for the Internationalization Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2012Jul/0010.html http://www.w3.org/2012/07/i18n-charter/charter.html Mozilla has the opportunity to send comments or objections through next Friday, September 14. Please reply to this thread if you think there's something we should say. The charter seems reasonable. I think we should send a statement of support for the i18nwg's activities, as I generally think they're very useful. Maybe something like Mozilla supports the continued work of the i18nWG and considers its contributions to W3C efforts to be valuable to the Web. or whatever ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reftest manifest width/height conditions for mobile reftests
On 09/12/2012 03:29 PM, fantasai wrote: On 09/12/2012 03:06 PM, Robert O'Callahan wrote: On Mon, Sep 10, 2012 at 11:24 PM, jmaher wrote: I think we need to coordinate with the W3C testing people to come up with a common cross-browser reftest size before we make a decision here. I had worked on trying to figure out what the other consumers of reftests use back in the Spring and I didn't come up with anything conclusive. I do know we need our height to be<=600. Do we have real contacts (not newsgroups) of the other consumers so we can get a decision made faster? Elika, do you think there's any chance the W3C might want to set the maximum size of reftests to less than 600x600? If not, then we can change all our reftests to be 600x600 and we won't have to worry that later the W3C makes us resize them all again because they're still too big. No idea. I think there were some side-discussions of what to set it at, but no conclusions IIRC. I'll ask about it. Thread at http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html I'll make sure we get answers from Apple/Opera/Google/Microsoft through their CSSWG reps if nothing else. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reftest manifest width/height conditions for mobile reftests
On 09/12/2012 03:06 PM, Robert O'Callahan wrote: On Mon, Sep 10, 2012 at 11:24 PM, jmaher wrote: I think we need to coordinate with the W3C testing people to come up with a common cross-browser reftest size before we make a decision here. I had worked on trying to figure out what the other consumers of reftests use back in the Spring and I didn't come up with anything conclusive. I do know we need our height to be<=600. Do we have real contacts (not newsgroups) of the other consumers so we can get a decision made faster? Elika, do you think there's any chance the W3C might want to set the maximum size of reftests to less than 600x600? If not, then we can change all our reftests to be 600x600 and we won't have to worry that later the W3C makes us resize them all again because they're still too big. No idea. I think there were some side-discussions of what to set it at, but no conclusions IIRC. I'll ask about it. ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
