Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blaze messing up with inline style definition #159

Closed
hwillson opened this issue Nov 15, 2016 · 6 comments
Closed

Blaze messing up with inline style definition #159

hwillson opened this issue Nov 15, 2016 · 6 comments

Comments

@hwillson
Copy link
Contributor

Migrating/combining this issue from meteor/meteor#3765 and meteor/meteor#3869 (I've verified this problem still exists with Blaze 2.2.0). Both issues relate to Blaze's style/class attribute handling. A potential solution to these problems has been outlined in meteor/meteor#3765 (comment) and a pull request has been encouraged.


(meteor/meteor#3765 originally reported by @steph643)

Consider the following code:

<head>
  <title>hello</title>
</head>

<body>
  <h1>Welcome to Meteor!</h1>
  {{> hello}}
</body>

<template name="hello">

  <button>Click Me</button>

  <p>You've pressed the button {{counter}} times.</p>

  <h4>Case 1: as expected</h4>
  <p style="{{#if counter}}visibility:hidden{{/if}}; color:red;">Still waiting for a click!</p>

  <h4>Case 2: unexpected behavior, by omitting the final semicolon in the inline style</h4>
  <p style="{{#if counter}}visibility:hidden{{/if}}; color:red">Still waiting for a click!</p>

</template>
if (Meteor.isClient) {

    // counter starts at 0
    Session.set('counter', 0);

    Template.hello.helpers({
        counter: function () {
            return Session.get('counter');
        }
    });

    Template.hello.events({
        'click button': function () {
            // increment the counter when button is clicked
            Session.set('counter', Session.get('counter') + 1);
        }
    });
}

If you click the button once, the text "Still waiting for a click!" disappears as expected in case 1, but remains visible with the wrong color in case 2.

The issues is caused by Blaze doing some reordering inside inline styles.

Here is Blaze-generated html:

Case 1 (reordered, but working):
<p style="color:red; visibility:hidden;">Counter is even!</p>

Case 2 (reordered, not working):
<p style="color:red visibility:hidden;">Counter is even!</p>


(meteor/meteor#3869 originally reported by @Buom01)

Hi, this can be an real probleme with semantic-ui for exemple.

I have this:

   <div class="ui {{#if smallScreen}}{{else}}three column grid{{/if}} stacked segment">
       <div class="column">
           <div class="ui {{#if smallScreen}}vertical{{else}}horizontal{{/if}} segment">
               <h1 class="ui header">Gratuit</h1>
               <p>....</p>
           </div>
       </div>
       <div class="column">
           <div class="ui {{#if smallScreen}}vertical{{else}}horizontal{{/if}} segment">
               <h1 class="ui header">Moderne</h1>
               <p>....</p>
           </div>
       </div>
   </div>

Render is correctly on smallScreen (and largeScreen);

   <div class="column">
       <div class="**ui vertical segment**">
           <h1 class="ui header">Gratuit</h1>
           <p></p>
       </div>
   </div>

But, if we resizing from smallScreen to largeScreen and revert, we obtain;
(Also obtain this when resize from smallScreen to largeScreen or from largeScreen to smallScreen)

   <div class="column">
       <div class="**ui segment vertical**">
           <h1 class="ui header">Gratuit</h1>
           <p></p>
       </div>
   </div>

The order and the display went wrong....

(see images in original post)

@maxnowack
Copy link
Contributor

probably related to #30

@mitar
Copy link
Contributor

mitar commented Nov 15, 2016

Is Blaze parsing inline styles? Interesting. I thought it sees it simply as a string. In the latter case it should not reorder things. Imagine that this is some other custom attribute, like data-fobar="test {{value}} test2". You would want the order to be preserved.

@mitar
Copy link
Contributor

mitar commented Dec 4, 2016

Isn't this a duplicate of #141? To me it seems like exactly the same issue.

@mitar
Copy link
Contributor

mitar commented Dec 31, 2016

So about repeated class names and order of them, see #30. I think those are not by standard so Blaze does not have to support them. In general I think it is more common that one has to clear all potential duplicates and that order of classes does not matter.

For style issues, this is a duplicate of #141.

@mitar mitar closed this as completed Dec 31, 2016
@mitar
Copy link
Contributor

mitar commented Dec 31, 2016

As a consequence of fixing #141, in fact, order inside inline style and class attributes is now preserved.

@mitar
Copy link
Contributor

mitar commented Dec 31, 2016

Now that order is preserved, it is unclear if it can happen that ; is missing inside inline styles. There is a TODO for that in joinValues method but I would need an example test case for it to fail to see how it fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants