http://www.facebook.com/pages/Hindustan-Technologies-Private-Limited/318300758211251
As part of our css devtools we need a way to check that a css property value is valid. This is used to validate
the value onkeyup. Our current solution is to call the following method on each keypress:
function validate(aValue)
{
let name = this.prop.name;
let value = typeof aValue == "undefined" ? this.prop.value : aValue;
let style = this.doc.createElementNS(HTML_NS, "div").style;
style.setProperty(name, value, null);
return !!style.getPropertyValue(name);
},
The problem with this solution is that it spews css error messages for invalid property values, but we could
work around this with:
let prefVal = getPref("layout.css.report_errors");
setPref("layout.css.report_errors", false);
try {
style.setProperty(name, value, null);
} finally {
setPref("layout.css.report_errors, prefVal");
}
It occurs to me that we are also adding autocomplete to the properties, so can any of you guys think of:
1. A better way to validate css property values.
2. A way to get a list of possible property values for a given css property (this could be used for
autocomplete and validation).
3. A better way to do both 1 and 2 ;o)
(Continue reading)
Here are today's Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki <at> mozilla.org. Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help! 1) inherit ( http://mzl.la/HF2vAM ) 2) background-clip ( http://mzl.la/HJGvSb ) 3) clip-path ( http://mzl.la/eGdxye )
While thinking about what a proposal to WHATWG about the printCallback-API should look like, I've came
across the following edgecases.
* the context passed to the mozPrintCallback function has a `canvas` property. I think this `canvas`
property should not exist on the mozPrintCallback passed in `ctx` and should return `undefined.
What should this canvas be? If it's the canvas of the print-document, performing operations like
`appendChild` to the HTML tree, that gets printed, can cause issues, as it's assumed that this tree is
static and can't change. On the other side, the `canvas` might refer to the canvas in the DOM, but this
canvas was removed in the meantime (= during the time frame the printing starts and the callback is called)
maybe .
Instead, I propose the second argument passed to the callback should contain the `width`, `height`, `id`
and `name` of the canvas as at the beginning of the printing process.
The usage of the mozPrintCallback might then look like this:
canvas.mozPrintCallback = function(ctx, obj) {
console.log(obj.width, obj.height, obj.id, obj.name);
// ...
}
* The current implementation sets the size of the rendering context to the size of the actual canvas on the
screen if in preview. The canvas context is then scaled, such that the behavior of the canvas context
"feels" the same in normal DOM usage. While this works, this might cause problems when using
`getImageData` on the canvas.
Imagine the print preview has a zoom set to 10%. If the canvas has normally a width of 100px, it might now only
have 10px in preview. The internal used context of the canvas is then only 10px in width, but if the user
requests imageData with width 50px, this gets mapped down to 5px (due to internal scaling). But then the
(Continue reading)Please look at: <http://www3.bell.net/monique.richter/ThreeImagesSpacedEvenly%20-%204%20areas%20now%20-%20divs.htm> and confirm if a bug and if so, if it is known. -- -- Thank you, Gus
HostMath is a powerful interactive mathematical expressions editor. It uses WYSIWYG-style editing and allows creating mathematical equations through simple point-and-click techniques. 1. Many pre-defined Templates and Symbols in well-organized palettes that cover Mathematics, Physics, Electronics, and many other higher educations 2. Fine adjustment for Template shapes, gaps, and thicknesses with visual interface 3. Multiple Undo and Redo 4. Can generate equations as MathML. MathML will allow you to copy and paste math into many applications that understand MathML. URL: http://www.hostmath.com/
The Tools and Automation team is working on setting up automatic
synchronization between the CSSWG test repository and ours. There
will be two folders:
- one for submitted tests, which will be automatically pushed
to Mozilla's directory on the CSSWG hg server
- one for received tests, which will be semi-automatically
pulled from the CSSWG's approved directory on the CSSWG hg
server
(The second step is semi-automatic because we'll need to annotate
the reftest manifests for any new tests to match our current
behavior.)
The question right now is where to put these tests. We can put
them under /layout/reftests/w3c/ or we can put them under
/testing/w3c-tests/css. The former keeps them closer to existing
reftests. The latter lets us put all W3C-synchronized tests near
each other as we add other test suites in the future.
Any comments from the module owners?
~fantasai
> What I think you need to do is:
> -- in nsHTMLCanvasElement::CopyInnerTo in the IsStaticDocument case, set up
> a reference from the cloned-for-print canvas to the original canvas
> -- in nsSimplePageSequenceFrame::PrintNextPage, before you render the page
> via nsLayoutUtils::PaintFrame, traverse the child page frame's frame
> subtree (see FrameChildListIterator and its users) looking for
> nsHTMLCanvasFrames (via do_QueryFrame). For each one, look up the original
> canvas, see if it has an "onprint" (or whatever we call it) event handler
> set on it. For those that do:
> -- Poke the printed nsHTMLCanvasElement's 2D rendering context
> (nsCanvasRenderingContext2D for now) to tell it to change its surface to a
> new surface created via
> renderingContext->GetThebes()->CurrentSurface()->CreateSimilarSurface()
> -- Synchronously dispatch the "print" event to the original canvas.
> -- That event should use a custom DOM event class (see for example
> nsDOMNotifyPaintEvent) with an extra field that's the 2D rendering context
> for the printed nsHTMLCanvasElement
The points above seem to work in a very hacked up first version :)
Instead of the event I use callback style for now. The first argument gets the rendering context and the
second argument is an object, that contains additional data.
You can find my current "test" file here:
https://gist.github.com/2230187
This is what the print output looks like (used "Save as PDF" option):
http://n.ethz.ch/~jviereck/drop/Preview_print_test.pdf
(Continue reading)Rob, thanks a lot for your step points on how to get this implemented - this is way more detailed then I've expected it to be :) > For each one, look up the original > canvas, see if it has an "onprint" (or whatever we call it) event handler > set on it. For those that do: If we use events here, there could be two callbacks listening for the same event. To keep it easy, I propose to define a new `printCallback` attribute on the nsHTMLCanvasElement, that takes a JSFunction as argument. Are there advantages in using an event instead of a simple callback that I don't realize? > -- Synchronously dispatch the "print" event to the original canvas. > -- That event should use a custom DOM event class (see for example > nsDOMNotifyPaintEvent) with an extra field that's the 2D rendering context > for the printed nsHTMLCanvasElement With the idea of the `printCallback` from above, the first argument would be the new created RenderingContext.
On 03/14/2012 05:56 PM, Jet Villegas wrote: > IIUC you're asking that we implement the default behavior for CSS3 Paged Media margin boxes: > > Margin boxes have an initial value of zero for padding, border and margin. The default height of top boxes is the value of the page box's top margin. The default height of the bottom boxes is the value of the page box's bottom margin. > The initial value for 'content' is 'none'. The initial 'width' and 'height' of margin boxes is 'auto'. > > http://www.w3.org/TR/2006/WD-css3-page-20061010/#populating-margin-boxes > > In other words, we won't be rendering any content for headers or footers. That depends on what's in our UA and user style sheet levels. Presumably the default for web pages will include the title/URL/timestamp/etc. like we do today. > You're also asking that we implement page size, and portrait vs. landscape: > http://www.w3.org/TR/2006/WD-css3-page-20061010/#page-size I would strongly recommend referring to the editor's draft for now. http://dev.w3.org/csswg/css3-page/ For various reasons (that have little to do with W3C and more to do with the printer industry and me being switched to other tasks like CSS2.1), the draft you link to is very out-of-date... We've also gotten some significant comments on the margin box sizing rules from Simon Sapin on www-style; if you're going to implement margin boxes, you'll want to track those discussions. http://lists.w3.org/Archives/Public/www-style/(Continue reading)
After thinking about the proposed ideas in Robert's first reply, based on the feedback to my raised questions (you guys are awesome, thanks!) and talking to some other people, I think it's best to drop the WebPrintAPI proposal and go with what Robert proposed. That requires two things to get implemented in Gecko: i) Implement a subset of CSS3PagedMedia to set the margin (at least the case = 0 to hide all the header/footer) and the page size. ii) Implement a new callback on the canvas element that is called during the actual printing to print directly to the printing backend. What's the best way to get the implementation going? For i), there seems to be a bug already: https://bugzilla.mozilla.org/show_bug.cgi?id=115199 I tried to understand what the patches are doing and couldn't figure it out for most parts. For i), is the way to implement this by continue working on bug 115199, or should there be a new bug that tries to implement only a very dump subset of the CSS3PagedMedia, such that one can set the margin to 0 and the page-size and that's it? From my intuition, the second part ii) might be "easier" to implement then the first part, as it is more contained and doesn't require to deal with new CSS rules. I'm therefore wondering if you think this is something I could try to implement. So far I have some basic understanding about how the printing stuff works, how the CanvasReneringContext is defined in the IDL and cpp file etc. Could someone give me some pointers where the actual printing of a canvas element to the printing context happens, such that I could try to implement the proposed callback? Best,(Continue reading)
RSS Feed3 | |
|---|---|
16 | |
43 | |
7 | |
15 | |
14 | |
21 | |
32 | |
20 | |
21 | |
15 | |
9 | |
21 | |
22 | |
36 | |
13 | |
10 | |
19 | |
9 | |
26 | |
7 | |
17 | |
10 | |
3 | |
1 | |
1 | |
4 | |
26 | |
13 | |
5 | |
14 | |
34 | |
27 | |
37 | |
9 | |
35 | |
8 | |
18 | |
15 | |
18 | |
37 | |
50 | |
8 | |
26 | |
50 | |
43 | |
69 | |
55 | |
193 | |
7 | |
9 | |
3 | |
14 | |
43 | |
43 | |
12 | |
67 | |
48 | |
58 | |
52 | |
112 | |
74 | |
18 | |
31 | |
40 | |
54 | |
25 | |
58 | |
51 | |
49 | |
93 | |
23 | |
76 | |
21 | |
25 | |
28 | |
23 | |
53 | |
35 | |
4 | |
16 | |
31 | |
18 | |
127 | |
31 | |
32 | |
85 | |
24 | |
26 | |
29 | |
33 | |
23 | |
64 | |
115 | |
91 | |
42 | |
21 | |
23 | |
34 | |
162 | |
53 | |
89 | |
26 | |
18 | |
2 | |
29 | |
84 | |
59 | |
47 | |
45 | |
27 | |
59 | |
45 | |
62 | |
88 | |
66 | |
5 | |
19 | |
42 | |
1 |
