Blaze messing up with inline style definition #159

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

Comments

Projects
None yet
3 participants
@hwillson
Member

hwillson commented Nov 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@maxnowack

maxnowack Nov 15, 2016

Contributor

probably related to #30

Contributor

maxnowack commented Nov 15, 2016

probably related to #30

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Nov 15, 2016

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Dec 4, 2016

Collaborator

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

Collaborator

mitar commented Dec 4, 2016

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

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Dec 31, 2016

Collaborator

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.

Collaborator

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 Dec 31, 2016

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Dec 31, 2016

Collaborator

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

Collaborator

mitar commented Dec 31, 2016

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

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Dec 31, 2016

Collaborator

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.

Collaborator

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