Re: [dev-servo] Query on properties.mako.rs for CSSparser

[Josh Matthews]

Sorry, my fault for using links that only reference master, not a stable 
revision. I meant that you should add a new argument to the 
get_specified macro arguments.


Cheers,
Josh

On 2015-11-05 1:28 PM, Pranesha Shashwath Kumar Kattepura Jayabheema Rao 
wrote:

Hi Josh,

The content in the 6506 in the link you shared in your previous mail
i.e., http://mxr.mozilla.org/servo/source/components/style/properties.mako.
rs#6506 , and the content in line 6506 in properties.mako.rs in GutHub are
different. Did you mean to ask me to add the argument --
`$error_reporter: expr' as argument in Computed::context but
::context is already an argument in cascade function.

Yours sincerely,
Pranesha Shashwath Kumar
[Campus ID: 200112642]

On Sat, Oct 31, 2015 at 12:27 PM, Josh Matthews 
wrote:


In answer to your question, the change that is causing all of these errors
is
https://github.com/GauriGNaik/servo/commit/c8b79b964d9f5225196a307102442abf3352c43b#diff-1816aa410246f8915a124610d4e5bc3cR5620
..

You need to modify
http://mxr.mozilla.org/servo/source/components/style/properties.mako.rs#6506
to accept a new `$error_reporter: expr` argument, and then you can pass
`$error_reporter` as an argument when required.

I suspect you'll need to add a new argument to the `cascade` function, and
pass that for each invocation of `get_specified!`.

Cheers,
Josh

On 2015-10-31 10:01 AM, Pranesha Shashwath Kumar Kattepura Jayabheema Rao
wrote:


Thanks for the info. The small change we made to struct ParserContext in
parser.rs seems to have lots of dependencies. This seems to be a scenario
of metaprogramming where a new function is being created at run-time.
Could
you please help us understand if changing this function to accept 4 values
was valid change to happen. If yes, what is the datatype of the 4th value
being accepted. As I understand the new scenario for datatypes in the
function below is as follows :

substitute_variables_display(value, _properties, |value| ...)

1st - value

2nd - _properties

3rd - *a part of _properties*

4th - |value|


I believe the 4th new argument is being created in the 3rd position as
described above. So, the new function may look something like this:

substitute_variables_display(value, _properties, *new_value*,
|value| ...)


Could you please let us know the following:

* Is my understanding of the function being translated from 3 argument
function to 4 arguments one as I described above correct

* was this translation supposed to happen, or should it have been a 3
argument function itself.

* If yes, what is the datatype of this argument that got created -- what
could be the simplest way to solve it - we can either assign a default
value to the *new_value, *or we can add a defunct value at every function
call of this function. We just wish to make sure that another chain of
dependencies is not created.


Yours sincerely,

Shashwath


On Oct 31, 2015 1:17 AM, "Josh Matthews"  wrote:

This is a tricky one. I suspect if we look closely at the error messages,

they would actually be pointing at a line _inside_ of the `get_specified`
macro, rather than directly at users of the macro. Specifically,
`get_specified!(get_box, display, value)` ends up expanding as something
like this:

substitute_variables_display(value, _properties, |value| ...)

which is indeed a function that takes 3 arguments on master (ie.

http://mxr.mozilla.org/servo/source/components/style/properties.mako.rs#5617
) and presumably has been modified to take 4 in your branch.

Does that make sense?

Cheers,
Josh

On 2015-10-30 10:00 PM, Pranesha Shashwath Kumar Kattepura Jayabheema Rao
wrote:

Hi,


 We are getting an error "This function takes 4 parameters but 3 were
supplied" for all the instances of the function get_specified!.

 When I look up the definition of the function at line 6505 in
properties.mako.rs it looks as follows:
macro_rules! get_specified( ($style_struct_getter: ident, $property:
ident,
$declared_value: expr) => { concat_idents!(substitute_variables_, $
property)( $declared_value, _properties, |value| match *value {
DeclaredValue::Value(specified_value) => specified_value,
DeclaredValue::
Initial => longhands::$property::get_initial_value(),
DeclaredValue::Inherit
=> { inherited_style.$style_struct_getter().$property.clone() }
DeclaredValue::WithVariables { .. } => unreachable!() } ) }; );
As I understand it the function rightly accepts only 3 parameters. Could
you please correct me if I am wrong. I do not see a fourth parameter
being
asked for here.

Yours sincerely,
Pranesha Shashwath Kumar
[Campus ID: 200112642]


___

dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo



___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo



___

Re: [dev-servo] Stacking order of inline stacking contexts

[Robert O'Callahan]

On Fri, Nov 6, 2015 at 12:53 PM, Martin Robinson 
wrote:

> By way of example:
>
> 
> 
> Line 1
> Line 2
> 
> 
>
> The two spans are inline, so normally "Line 1" would stack underneath
> "Line 2" due to tree order. Since "Line 1" establishes a stacking
> context (via the opacity style property), it stacks in tree order with
> the divs (which also establish stacking contexts via their transform
> style properties). The way I implement this is to always insert inline
> stacking contexts into the positioned content section of the display list.
>

That's right.


> The issue I'm having now is that I cannot figure out where or how this
> behavior is described in the spec [1][2]. Both the divs and the first
> span seem to be treated as "positioned descendants" as described in
> Section E.2.8.
>
> I still plan to implement the same behavior as Gecko and Chrome, but I
> would be very grateful is someone could help shed light on how this
> relates to the spec. Thanks!
>

Yeah, it's not in Appendix E, though it probably should be. For 'opacity'
this is described in the CSS3 Color spec:
http://www.w3.org/TR/css3-color/#transparency

> If an element with opacity less than 1 is not positioned, implementations
> must paint the layer it creates, within its parent stacking context, at the
> same stacking order that would be used if it were a positioned element with
> ‘z-index: 0’ and ‘opacity: 1’.
>
All properties that induce a stacking context behave this way.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo